On Saturday/Sunday, I went to AngelHack SF and did a solo-project that ended up placing 2nd amongst +80 teams and netted me a $2500 credit from Firebase and an invitation to AngelHack's accelerator.

Am I a bad developer, too? Or is the hiring practice of reducing someone's technical competence to a handful of esoteric questions arbitrary and broken?

I am much more proud of the things I have built and the reputation I have with the other developers I have worked with than I am of my ability to find the longest common subsequence between two strings.

I'm guilty of asking these kinds of questions, too. The truth is it is incredibly hard to gauge a programmer's skills and figure out whether they fit into your team over the course of a half-hour interview, and nobody really has figured out a good way to do it. We're stuck with arbitrary questions that yield false negatives (and positives) simply because there isn't a better solution.

Edit: Aaannd in the course of writing this I received an offer letter and an email from someone at a16z asking about my AngelHack project, so I guess my job hunt is over. When it rains, it pours.

The irony is whenever someone posts some esoteric "gotcha" programming trick here on HN, inevitably there'll be comments like "have to include this in our next interviews."

So what would you do differently? This is a genuine question after I came off 3 months of interviewing daily. I'm curious what does represent a good developer and how to decide this in 30 minutes over the phone? What's important? - Past projects? - Communication? - Open source contributions? - Ability to write code? - Telling me how they'd Google a problem? - How to break down problems? - Some % combination of these?

My interviews are generally structured: 10 min: introduction to the role, expectations, motivations, try to start a conversation, get a feel for the candidate, nerves etc 15 min: technical questions: - fundamentals on the job's tech stack (must provide code) - turning a requirement into a design - troubleshooting issues (db performance, web server issues) 5 min: - wrap up, q&a

You mention that there isn't a better solution. IMHO, I disagree.

I think Github has figured out a way. They've been around 5 years and haven't fired anybody and nobody has quit.

Most firings are due to a job / job skill mismatch. At Github, they do a week long paid interview so both sides really know what they're getting into.

I don't work at Github, but am such a fan of their company.

Lesser companies simply have to take more chances on people if they want to have a shot at growing their teams. They will naturally fail more than companies that don't have to take that shot.

Also, GitHub just have 166 employees (https://github.com/about) - presumably not all engineers. Any ten random selected medium sized software companies easily eclipses their volume.

Certainly the hiring practices of Google et al, generally the worst perpetrators of cs bingo in my experience. Started a startup, you say? Rebuilt a non-trivial webapp? Won a hackathon? That's great, but we're going to need you to implement red-black trees and variations of fizzbuzz until your brain bleeds.

But I didn't give a crap, because hiring is something you're kind of coerced into doing (it's not technically required, but not doing interviews looks bad at promotion time). And I hated doing interviews with a passion, so I'd just give them one impossibly hard question, which is easier than asking a bunch of questions.

Sometimes I have to stop myself doing this before conducting interviews. I think it's an ego thing, or perhaps an insecurity. When I worked at Amazon the culture drove this kind of rubbish and skewed our hiring process immensely.

There was something perverse about being in an interview loop, all 8 of us "not inclined" to hire a single candidate because they missed an recursion terminator in a solution to something properly complex and scratched out on a whiteboard in 15 minutes. All of us nodding like "that's so stupid" and I was sitting there 100% certain of the 8 people in the room the 7 of us who hadn't conducted the same interview 50 times would drop a bollock somewhere along the way. Yet there was no way this "otherwise competent, and quite nice guy" was as technically astute as all of us gathered here today indulging in our nice cup of ego massage while other people got actual work done.

Now when I interview candidates I want to see some code you have written you are proud of. Above all, I'm looking for pragmatism, effective reasoning and discipline in execution.

I love the idea of a paid working trial of some length, followed by a permanent hire but I've yet to convince the powers that be that it's an effective strategy.

I prefer to hire a candidate that might take 2-3 months to get productive but have some really innovative ideas, that others in the company might have missed. Puzzle questions do give me a sense of how someone approaches and solves problems, and I think you can infer how they will handle real problems since the building blocks to problem solving are essentially the same regardless of what domain. Solving puzzle questions is just a component of things I look for:

1. Experience in solving challenging problems 2. Good university results 3. Personality fit, easy to get along with 4. Leadership potential 5. Enthusiastic/passionate

Not all five are needed, but candidates need to be strong in more than 1-2 areas.

If you have issues with interviews specifically, you could enter a TopCoder competition, or Google Code Jam, and use that as evidence that you can solve those types of problems.

As a passive job seeker, I think this is something I've used to filter out companies. Ones that want to hire someone yesterday are more likely to suffer from poor planning and may only care about short term results.

I'd rather have someone who may take 2-3 months to get up to speed, and then spend years with me returning that investment more than a simple mercenary that will be with me a year or two and then move on.

How long of a trial are you thinking of? If it's a significant amount of time, I think this could be hard to do from the perspective of the candidate.

If I'm currently employed, there's probably no way I'm going to quit my job for a month-long paid trial period somewhere else. If it didn't work out, I'd find myself without a job and would be forced to take a hopefully short sabbatical for more interviews (and this wouldn't be possible at all for people who haven't saved up enough money to do so). It just seems too risky.

If it were longer, say six months, I might consider it, but I'd expect a decision to be made well before the end of the sixth month--that way if you didn't want to hire me full-time I'd have time to talk to other companies before losing my income. Even with this concession, I'd have to want to work for your company an abnormal amount to do this, though.

Perhaps a happy medium is a take-home project taking one or two weeks of part-time work, paid for at market wage.

Would you be willing to share any of the questions you asked? Your description here has piqued my curiosity.

However, I do meaningfully disagree about "variations of Fizzbuzz". It does make sense to vary fizzbuzz, if you suspect that your candidate will have literally memorized the solution, character for character. If that's a concern, though, trivial variations are sufficient: replace the 5 with a 7, or change the ELSE case from "print the number" to "print nothing", or something.

I agree that if your "variation" makes it "interesting", you're not doing Fizzbuzz.

Whether or not interesting programming puzzles are a good element of interviewing, well, there continues to be a wide range of opinions on that.

What I was responding to was "variations of fizzbuzz until your brain bleeds". Which I interpret to mean doing a fizzbuzz, then the interviewer changes it a bit, and a bit more, and keeps dragging it out, having misinterpreted its purpose. Certainly the one and only "fizzbuzz" test you give a candidate can vary from individual to individual.

It may be counter-intuitive, but the more qualified you are, the longer you have to look for a job. A fresh-faced junior developer just out of college can be hired pretty quickly, because he/she isn't a big risk: the salary is lower, the responsibility is lower, and it's assumed there will be some adult supervision from an experienced developer. A senior developer is expected to hit the ground running, and a bad fit can create a lot of team friction and technical debt in a short time. (And your own standards are higher, so not every company will do.)

I think that the problems with technical interviews is that they focus more on algorithms than actual code. While this practice is good for recruiting students out of school who should know by heart the most efficient search or sorting algorithms, it puts people who have been in the industry or who often work in freelance jobs at a considerable disadvantage.

Unless you are working at Google or Facebook where efficiency is super important, the interview questions that Silicon Valley companies ask often do a bad job of filtering out the right candidate.

I thought that your hack was very good. I think that you could turn it into a business if you wanted to.

I was told that the only reason I didn't win the grand prize was some of the judges didn't think I could have made the app by myself during the competition/I had cheated.

Honestly, I'm more flattered that they thought I was too good to win than I would have been if I had won. :)

Right on the spot I was told I wasn't a perfect match. Not directly saying it but definitely implying it, they said they needed someone who can actually code.

I guess having deployed multiple projects and code to show for it isn't worth anything if you can't code a variation of fizz buzz.

The hiring practice is a little off. If anyone ever asks me for advice on job hunting, I'll definitely tell them to exhaust all networking outlets e.g. programing meets, hackathons, friends of friends, before applying directly.

Despite all his colleagues, friends, and coworkers telling him he is proficient, keeping current in the industry, coding for fun, contributing to open source, proactively bettering his coding style and knowledge, and knowing a lot of theory, his mediocre interviews are enough to convince him that he's a bad developer. I'd wager that the problem is NOT his skills as a developer, but his skills at interviews... especially since he seems to have gotten a lot of his previous jobs through networking.

>I am now in the buffer zone and have interviewed with close to ten companies to date.

Seriously??? 9 interviews without a job offer from companies which I'm assuming he didn't have any connections with, and despite all his past accomplishments, which he barely even mentions, that's enough to convince him that he's a bad coder and bad at his job.

Come on dude. Get real. You're probably a great developer and suck at selling yourself. What's more likely? Being bad at the thing you love, that other people agree you're good at, and have been doing for years, or the thing that you admit you find difficult and in which you have almost no interest?

Job applications are very stop-start affairs. Post a job ad. Wait a couple of weeks for it to finish. Then leave the collated resumes on the hiring manager's desk for a while, then someone prods the manager "why don't we have a -foo- yet?". Manager starts the callaround, does the first round of interviews, makes a shortlist, then they sit on the desk again. Maybe discuss potentials with other staff, but it peters out. There's so much other stuff to do! Then someone says "Why don't we have a -foo- yet?". Rinse, repeat. It certainly doesn't always happen, but it's common enough.

At one place I worked, I was basically the sole applicant - my friend worked the other support role and recommended me. The HR officer (CEO's wife...) called me in. That went well, so I had a second 'confirm this guy isn't an idiot' interview with the CEO. A couple of polite proddings received no response. I asked my friend and he said "I thought we did agree to hire you, that's what I heard". A couple more proddings and the CEO said 'Yes'. But the HR officer wasn't responding. At this stage it was six weeks from first interview to CEO 'Yes'. We hadn't even discussed salary yet. I was so desperate for a job at the time, that I just rolled up and started working, because fuck it, the worst that can happen is that it's abysmally low and I go elsewhere - it's not like my days were productive otherwise. A panicked call from the HR officer the next day did a hurried salary negotiation.

Now sure, the last part of this story isn't typical (though I find it funny), but it took 6 weeks for me to get a job with a small, busy company who had staff with prior positive experience with me as a colleague and no competition. One month is nothing when it comes to applying for skilled work.

Imposter syndrome does sound quite right. Or the guy is just depressed pretty hard.

Setbacks at the interview stage rank among the most depressing and confidence sapping experiences in my professional career. I think it could make anyone fairly depressed, but IANAD.

Now have you heard of a developer that couldn't pay his bills?

That's why he wouldn't want his daughter to know what he does.

Very few career paths offer absolute job stability and an infallible guarantee of employability. That's no reason to be embarrassed of a career choice.

I've seen many smart coders falling short in real-life scenarios, where they refuse to take the shortcuts and make the trade-offs that most high-paced production projects need to deliver on time. And on the other side of the fence I have seen mediocre programmers deliver quality apps on schedule by allowing themselves to take what to a purist would look like shortcuts. More often than not, companies prefer the latter one.

Perhaps many employers have a process of surfacing stuff like that during the interview phase? Every time I interview someone to fill a position working with developing and delivering applications written in X, and all they want to do is tell me about the awesome type system in Y, alarms start to sound in my head.

It sounds to me like the opposite of what you're saying: he's good at delivering to production, but he's not good at pet interview questions.

That seems like a rather silly conclusion to draw. I actually think these sorts of hasty conclusions are part of the problem with the hiring process in the industry.

http://steve-yegge.blogspot.com/2007/06/rich-programmer-food...

Yes, I would certainly question their relevance to most jobs. But we're not talking about most jobs, we're talking specifically about software development jobs. Where they are incredibly useful.

Yes performance is a feature but realistically you can get away with some fairly awfully performing code for a long time in most situations.

I remember a conversation a while ago where people we asking if you could have a language that offered X increase in performance over C for X increase in processing time what value of X would you pick? In most cases people are willing to trade a lot of performance for a lot of productivity.

The employee had to explain that they couldn't deploy this algorithm because it was O(N^3) whereas the (already deployed) one that was doing worse on the test-data was O(N log N). The test-data was two orders of magnitude smaller than what could reasonably be expected while deployed.

I didn't mention not being able to reason out the complexity, only saying its O(N^2) off the top of your head when presented with some method.

To be sure, not being able to reason outside of the canon is a long-standing occupational hazard and trait of the humanities, so there could be something a little more pathological in perpetuating these interviewing techniques.

interviewer : "what's the time complexity of blah"

me : "hmm... O(1)"

interviewer : "what's the space complexity?"

me : "fuck, oh, I don't know"

interviewer : "well, think about it. no stress"

me (2 seconds later) : "oh, right, yeah, O(n)... of course"

Not saying I'm proud of not taking the time to think a problem through, but sometimes people act really weird when under the gun.

Trite though it is, admitting that you don't know truly is on the path to wisdom.

Not taking time to think things through is endemic in the workplace, not just an interview quirk.

in the real world, many O(N) algorithms are in fact O(I don't know) because of unexpected or unpredicted behavior from language, compiler, interpreter, runtime, os, etc.

If they can tell you in Big O notation why its bad for large inputs then great, but so long as they can tell you why that's what really matters.

That is -- anytime you write a loop, you'd better think about what's inside it (and how long those things will take), and -- given the amount of data you might be sending through that loop -- if that's a problem or not.

I want someone to notice that they're making a remote call in a loop when it could be batched, cached, etc.. I don't want them to spend 2 days optimizing an algorithm tinkering with a bit of text that yes, is inefficient, but in practice is only going to take a few milliseconds anyway and isn't a hotspot.

O(N^2) means that your operation gets n times slower each time n increases.

2000^2 is 4 million. (n log n = 6600)

200,000^2 is 40 billion. (n log n = 1 million)

My point is for a lot of cases it doesn't matter, and just because someone can't throw off the top of their head the O complexity of some algorithm they just wrote in a stressful interview does not mean they don't understand the concepts.

Besides a O(N log N) algorithm over 10 or 100 items is not going to cause any issues. In the case of your standard CRUD application that's what you are going to be dealing with.

> Besides a O(N log N) algorithm over 10 or 100 items is not going to cause any issues. In the case of your standard CRUD application that's what you are going to be dealing with.

I think you mean n^2. n log n is generally considered pretty decent.

But you're wrong, I know from experience that simple CRUD apps can suffer from grindingly poor performance, caused by, let's say, optimistic assertions of data volumes.

I am yet to have seen a basic CRUD app that had performance issues due to a bad coding algorithm. Certainly from poor queries but never from an bad algorithm.

Keep in mind I would say that a simple CRUD app with millions of entries is no longer a simple CRUD app.

But yeah, case in point: I ran a small BB-style web forum a number of years ago. As it grew larger (on the order of 10k posts - hardly earth shattering for a web forum), the load on the server got unsustainable, and the page loads were really slow. It turned out that the algorithm to decide if a user had seen a post was to maintain a list of seen post IDs for each user, and compare them at each page view. For active users, the number of seen posts obviously approaches the number of posts: n^2.

select * from table;

Not nearly as relevant for someone using scripting languages and building UIs.

I've used slow web pages that show a lot of items or data. One way to make them slow is O(n^2) DOM manipulation (e.g., inside a loop over items in a page, O(n)-searching the page for something).

Knowing complexity theory isn't the only way to find performance problems, and sometimes isn't even relevant, but it sure is helpful.

Sometimes you have to make a decision to just go with the inefficient solution, but I'd like it to be an informed decision if the codebase is one I have to work with and maintain in production.

> And for all of this I still blunder my way through an exercise to write a function which returns a boolean in response to the question of whether sequence A is a sub-sequence of sequence B. I still draw a blank when asked what the magnitude of complexity is for the guests function I just wrote (damnit, of course calculating the permutations of a list is n-squared, but this is an interrogation of the random trivia I can manage to recall and I feel like a deer in the headlights).

That does, to me, sound like you do, in fact, have a problem with interviewing. The article is light on concrete facts to build off of, but if you're the kind of person who represent yourself to me (interviewing you) as having such an impressive toolbox as you certainly do seem to have in your possession, and then go on to fail to write a simple function and answer one of the most basic analytical (and, opposed to many other stupid gotchas/shibboleths, actually important) questions in computer science, then my "talker, not doer" red flag goes up, and you're going to have an uphill battle from there.

Basically, it's a case of over-promise and under-deliver.

Again, there is precious little concreteness to build off of, so this is very speculative: try to "modesty-fy" your CV and make sure you don't come off as bragging in any way in the beginning of the interview: under-promise. Also, do some whiteboard code katas. Then do the simple task, ask for help if you black out, and then put in the punch-line: "Actually, there's a really neat way to do this in Lisp".

I really have to work on this.

You know what's worse than ennui? Being broke and jobless is. Going into debt because of a radical misunderstanding of job markets is worse.

I'm sure you are a perfectly decent dev, OP, and I'm sorry that the system isn't very well built. I wish you weren't in such an unpleasant situation (though this was definitely a solid approach to getting a bunch of conversations started). This rant is not really directed at you - No doubt you have learned the lesson already.

DO NOT QUIT YOUR JOB BECAUSE YOU ARE UNHAPPY. Find another job first. I do not care if you are a Jedi ninja code tycoon, there are no sure things. Your friend does not have the pull he thinks he does. The market is not good. Your savings burns faster than matches.

I suppose you are also at risk of working longer hours, risking your health.

Pick up either Spring/Java/Hibernate for the corporate "boring" market (but still well paid / plenty of offering) Or Rails / Django for the still cool startup market

You can make a good living as a CRUD app developer, many of us do just that. reading through SICP is a huge bonus, but not a requirement to get a job in this "improving, but not yet fully ready for functional programming" world.

Did you ask yourself sometimes if you are perhaps overqualified? or causing the impression that you are going to over complicate things? Did it occur to you that you are maybe making interviewers look stupid as you give them a functional solution you learned in SICP to a problem they had in mind a imperative, for loop, lot's of shared state solution to? Perhaps you are too good of a developer for your own good?

I interviewed and hired lot's of developers, and having someone "too smart" is sometimes as bad as having someone who is, well, the opposite...

Try to go to a professional mock interviews service, and check if it's indeed you being a bad developer or something else, check anything, gee, check even your breath, (not kidding, had candidates who were brilliant but simply had bad breath, I was the only one decent enough to tell them that I guess as they didn't understand why they can't seem to get a job) not that I'm saying that this is your problem, but don't go and say that you being a bad programmer is the reason without very serious investigation.

Take it as a debugging task, rule out anything, I'm pretty sure you are a developer much better than many others happily employed that the moment...

Java seems to be on its way out here.

I sent a detailed, ranty email to a recruiter explaining what exactly I was looking for and where I might fit, to save my time, their time, and the companies' time avoiding positioning me where I didn't fit. They laughed and had a good time reading my humorous email, but still didn't "get it" and tried to place me with company after company doing Java, BI shit.

Finally I said, "Look, do you have any Python jobs?" And they said, "Oh, Python!" and started handing me positions that made some fucking sense. I ended up accepting one of them.

You have a family and had a job, yet you decided you didn't like it, walked away because you weren't unhappy, but weren't happy, and decided to DO NOTHING for two months?

If I was interviewing you I would be concerned that I'm going to hire you and you're just going to walk away after a few months because you don't like working.

Just having technical chops doesn't mean it's easy to get a job -- in fact, I'd venture to say that personality and attitude go a lot longer in the hiring arena than your skills -- I'm much happier hiring someone with less experience who wants to prove themselves and has a decent work ethic and doesn't walk away from a challenge, but instead goes after it. And from personal experience, time and time again, that's the developer that makes your company successful over the kid who knows his shit, but can't stick with anything for long enough to see it through.

I recently switched jobs last year-- I'm in my 12th year as a professional developer, start-up and large company experience, in languages "that matter" -- still took me three months of constant searching to find a new position, and that was while I was still employed so there was no break in my employment record.

After you pass that their algorithm trivia test (subset sums? REALLY?), then they ask you to do a take-home test. The latest one is literally "here's some data, code up an interface. Be creative." No direction, no use cases. They barely explain what the product even is.

This isn't going to be easy. I've already spent four hours on it - getting a sense of their product and what their customers even want - and a few more hours thinking about it and then one hour just massaging the data. I can see six more hours ahead of me. I'm doing it mostly because it's a way to motivate myself to learn more about mobile interfaces, but it's really irritating. Perhaps I could use more boilerplate code (and I'm trying to use as much off the shelf stuff as possible), but what do they learn then?

One of my old employers was guilty of something even worse - their take home exam was "code up a bug tracker". I felt so embarrassed about that. Either they whipped up a basic thing in something that creates most of the forms for you (which tells us relatively little), or they spun their wheels for two or three days (trying to do it from scratch, likely not producing anything that good).

In fact, reading your post, I get the feeling that you're a better dev than me. You probably have more experience and a better grasp of the high-level concepts as well as the ability to translate that understanding into better, more bug-free code.

Even despite this, were we competing for the same job, assuming I'm qualified for it, I would probably get hired over you because confidence matters and I have no problem conveying confidence in my abilities during an interview. Job hunting has nothing to do with software development.

You don't need to work on your coding skills. They're fine. You need to work on your social skills.

To clarify: I do understand algorithmic complexity. You don't often study information theory and ordering while skipping Big-O and friends if you're into CS. I was rather mad at myself for missing it in an interview. I should know it but I struggle with it under pressure.

If it's not one thing it's another though... and the repeated failures to find market acceptance for all the effort I expend to be a good developer is draining. I don't think I had any specific intent before I wrote this. I've just been trying to write it for weeks because this is something I'm going through and it's not something I find easy to talk about. I started out hoping to find out more about myself but I'm just left with more questions.

I'm ten years into a career and have had a long passion for programming (ever since I was a young kid copying BASIC listings into a Commodore).

I targeted companies that I thought I'd fit with a person and agreed with the products they made. It's very disenheartening to find out that you didn't make the cut time and again.

I guess I'd advise you to ensure (1) you're going to open houses and tech meetups in your area and (2) be sending out several targeted applications per day for companies that you genuinely want to work for.

Note, I would advise you or any other techie to move to a tech city for work. I've lived in the boonies for a few years now, there's almost no work here, no point in living here unless you have a cushy remote job.

Why the rejetions? Has any company told you what exactly were the reasons for rejection? Ask for a reply from the interviewers and the specific questions. Don't get those questions wrong again.

  I contribute to a plethora of open source projects in a range of languages such as 
  C++, Perl, Python, and even various Lisp-like languages.

  Well my bookshelf is stocked...
  ...
  I enjoy mathematics. ...
  ...
  And for all of this I still blunder my way through...
  ...
  I still draw a blank when asked what the magnitude of complexity is for the guests
  function I just wrote.

  My input is N, and I loop from 0 to N, hence complexity is O(N).

  I loop twice, so complexity is O(2N).

  The input is M and N, my function has nested loops, 0 to M, 0 to N,
  complexity is O(M * N).
  
  My input is N and I divide and conquer recursively cutting in half... 
  that's (N/2)/2)/2)/2... lg N!

I'd also recommend studying for interviews seriously. Cracking the code interview, http://www.amazon.com/Cracking-Coding-Interview-Programming-..., it helps quite a bit.

    I loop twice, so complexity is O(2N).

Instead of thinking of this as a personal failure in yourself, think of it as a disability of the companies you are interested in. How can you help them see past their own nose?

You might want to take a lot more time working on that personality if yours. Everything you wrote in your post and your post's general tone screamed to me "humorless with a chip on his shoulder."

And dump the self deprecation bit. No one's gonna hold your hand here. I doubt you're a bad programmer, I just think you suck at being likable. Shitty, I know. Now do something about it. Much more than you've been doing. Be approachable. Politics will always get your much further than skill.

I don't know the guy, so I'm not qualified to comment on his personality. From the several paragraphs I have to decipher his personality, he doesn't seem like a bad guy, and he seems to be good at communicating his thoughts. Maybe he's just looking for jobs in all the wrong places?

I think you really hit on something here.

I think the concept of "scared money" applies here. He's interviewing from a position of weakness (not having a job in hand to fall back on) and that causes him to perform in a way that could be coming of as desperate and dejected to interviewers. Some people are better at hiding that than others, but i'm thinking the author might have an issue with it.

Interviews should be a lot more simple. How about sitting the potential candidate down after validating their resume and skill-set meets the requirements of the role with your developers and have them help the team out for an hour or two and see how they go. There are many other factors to consider like; are you a good fit for the team (personality wise especially), are you able to adapt to other coding styles and conventions you might not be accustomed to?

As Albert Einstein once said: "Never memorize what you can look up in books" — Google is the 21st century equivalent of a book. Why remember what you can Google? You might not know how to write that complex algorithm off of the top of your head, but that shouldn't matter. What should matter is knowing what to search via Google or a book to solve the problem.

As a web developer who uses a plethora of languages like PHP, Ruby, Javascript (Node.JS and jQuery), CSS, HTML and Python it's a given you won't know how to do everything. I consider myself pretty knowledgeable but the things I don't know, I Google. The difference between a good developer and a bad developer is whether or not you have the skills to find the answers to your problems not whether or not you know the answers off of the top of your head.

Another approach when hiring someone is sitting them down and ask them to build something, not solve a mathematical problem but actually build a website application or software application. Interviewing a web developer? Ask them to build a simple blog application or script that interfaces with the Twitter API and fetches 10 Tweets based on a hashtag...

That's my take on it anyway.

As if by being intelligent your daughter should value you and you would derive worth. How can anyone be proud of cashing in on the genetic lottery? Your family will only ever love you for how hard you work and how much you sacrifice. Whether programmer, or plumber. Big difference.

Seriously, this is what annoys me most about people I've interviewed - they rarely ask why they didn't get the gig.

Sometimes because they didn't answer the coding questions, sometimes its because we found lies on their CV, or we had 3 candidates who were better qualified.

If you don't ask, you'll never know the reason.

My guess is most of them never ask because most companies large enough to have a legal department tell their interviewers and managers not to answer that question.

I wonder if there is some way we can encourage companies to provide better feedback, like positive glassdoor rankings on companies that do it.

Would interviews start to change their questions? Would the programmers who questioned the validity of the questions asked get more or less respect from interviewers?

Shouldn't more companies be embracing the trial an employee for a week and have them try to solve some real problems?

Tech interviews seem very broken at most companies whereas the companies that have the most progressive interviewing process (like github) continue to see more qualified candidates than they can hire.

I'm sorry you couldn't find a job in 2-months, but there are many other people who have tried for far longer. Suck it up.

I don't know what your code's like, but I'm going to take a guess that it's above average. In my experience, people who think about the stuff you mentioned tend to write above-average code.

Let me tell you what I always looked for in technical interviews. I wasn't trying to determine whether a candidate was an utter genius who would offer novel and clever solutions to hard problems. That's too high a bar; most companies can't expect to consistently attract those types of candidates.

Instead, I wanted to see if candidates would write maintainable code. In other words, my #1 concern was whether the candidate was going to create a big mess for the rest of us to clean up. Will they pollute my functions with a bunch of special-case if statements because they had to add a new feature that doesn't fit into the current architecture? Or will they recognize the situation for what it is and start a conversation about changing the architecture? Will they take a class named Car and use it to represent a House, just because it exposes the method .door? Or will they recognize the importance of logical naming, create a new House class, and break out the .door method into a mixin? Stuff like that.

Not every interviewer makes that the #1 concern. We all have our pet peeves. But my point is, there's usually some very mundane, practical thing they're looking for. Not super-ninja-rockstar coder status. If you can determine what that practical concern is, you can then try to convince the interviewer why you're exactly what they need.

I know teamworking is a buz word, such as "passion" and "drive" also, I know esoteric algorithms are fun, but one has to face the reality that sometimes complexity hides somewhere else, not in the programming craft by itself.

Actually, if you are a start up, I think the real complexity hides in the business itself (ie: getting customers to pay you) and I am pretty sure the difference between a passionate normal programmer and one that makes lisp interpreters during breakfast is slim to the end goal of said start up (which is, let's remember, to make more money than what is spent).

I put myself on sabbatical after realizing that my needs were not being met on a regular basis by my job. While I'll allow short-term ROI to be negative, I will never allow my long-term ROI to be negative [3]. I took some time out of my life to spend it with my wife and young daughter, something which I'd never done in my life. It is a blessing.

However, in the first week of my sabbatical I get called up for an interview with Expedia for a senior Web dev position. I thought "hey, I've never worked in the USA before, this could be fun". My interviewer was a junior dev who, in the course of the interview, demonstrated that he had very little experience in interviewing (whereas I have conducted > 100 interviews). In the technical phone interview I was asked some esoteric questions about finding the intersection of two integer arrays, what the O-notation would be, and so forth. I came up with some half-assed answers, since it had been years since I thought of those things [1] and since I was tired (on sabbatical) and didn't care if I got the job I asked the interview plainly how often this type of problem comes up in his work routine. His answer: never. Not once. I mentioned to him that I don't understand asking these types of questions, and I have never asked something like that in an interview before. I thanked him for his time, and prompted removed my resume from the application process [2].

To wit, my phone interviewing tactics for a Web dev position contain the following questions:

    - when I type in a URL in my browser's address bar, press Enter, and then the page appears, tell me what happened technically in as low level as possible.
    - what are the main verbs used in the HTTP protocol.
    - something about CSS, JS, <backend language>, HTML
    - something about how to handle a situation like breakfix, sensitive data leakage, etc.

[1] In other words, I think of O-notation in the back of my head when I code (loops within loops, etc), but I don't lead with it.

[2] Oh my, they did not like this. Granted, I was working through their internal recruiting agency, but you'd think I just called their child ugly or something.

[3] That's my corporate-speak coming out. Basically, short-term negative ROI is akin to working really hard and losing a bit of sleep to see a project to completion. Long-term negative ROI is when the hard-work you are doing is not noticed by upper manager and you are passed over for awards, congratulations, and other extrinsic things.

Edit: clarity

Hey, that's one of my favorite questions as well! Great way to gauge depth of knowledge, and you can take it so many places afterwards (HTTPS / SSL, REST, etc).

The best answer I heard started with "well, the enter key press triggers an interrupt...., followed by discussion of browser / OS differences with respect to caching DNS info."

Now you didn't give a lot of details - maybe you're upset about being asked to implement mergesort. That would also be an exercise in memorization. I'm not condoning that.

Being able to analyze an algorithm from a time/space complexity standpoint is about whether you can reason about code. I think that is also a useful thing to find out in an interview.

Cons are: It is specific to web people, of course. And not really a programming question.

For a web position I have no idea why you would ask them to write a tree parser or binary search algorithm which I experienced not that long ago.

Asking about what happens at a low level when entering a URL however is a good question. Or perhaps asking how to do cross domain JSON requests etc...

Not only that, there are fewer language barriers when asking some canned binary tree bullshit. So a Chinese programmer doing an interview who barely speaks English can still proudly ask the candidate some crap about Heapsort and feel like he's done his job well.

I think I've had to ask for clarification a few times due to the interviewee answering the open-ended question with something I wasn't familiar with, but that's an excellent opportunity to gauge their explanatory skills anyway!

The former is a question about fundamentals, whereas the latter is a question about specific implementations. I agree that as a Web developer you should probably need to know what JSONP is, but it's also something that could be learned in about 5 minutes from Google.

I like it when a phone interview is basically a conversation. I don't like Spanish Inquisition-style interviews, so I like to start with something and watch it lead to other things. Of course, if the conversation drops dead I can refer to my notes and ask another question. With regard to the URL question, in the past I have allowed the interviewee to answer the URL question as best they can, and the ask questions to cover some of the gaps, and these questions can lead into JSONP handling and its ilk.

As an aside and a <rant type=small />, interviewing like this ensures that there is a natural flow and I'm keeping my interviewee's brain jumping between similar contexts. I hate it when I've been interviewed and I'm expected to context switch between algorithms (mergesort) to best practises (SOLID) to programming (implement REST with Jersey+Servlets). And this is all in a 30-60 minute "conversation".

For instance, say we have a list of Users and a list of UserIds that we want to filter on (but for one reason or another don't want to do the filtering in the database.) The problem of getting the filtered list of Users based on their unique integer UserId has nearly the exact same solution as finding the intersection of the two integer lists, one being the requested UserIds filter, and the other being the list of UserIds from our list of Users.

I hope you word it much better than that. You certainly do not want to hear what happens in as low level detail as possible. You would be there for hours if I were to actually answer that. As posed, that question is demanding an answer that explains how pressing a key on a keyboard works, how the operating system handles the input, how it passes it to the program, the details of sockets programming, a lengthy discussion on DNS, ethernet, tcp/ip, switching, routing, etc, etc. Unless that question is intended to see how the interviewee handles being given vague and useless directions, it seems to be quite bad.

The reason I interrupt them when talk about electrical signals starts (or, as you mentioned, typing a key), is that I mainly hire for Web development positions and would like candidates to understand how the Web works. This knowledge is especially important for when things break down. Knowing how electrical signals work would be useful if you had to do hardware, networking, or anything else, but I just want to know that a candidate isn't just creating Web services without realizing that latency exists because of DNS routing and network hops.

Edit: clarity

As we've seen repeatedly here on HN, interviewers often ask about things that do not pertain to the job itself. Therefore it's actually a pretty aggressive phrasing of a question meant to elicit the information you require, so I don't think you can necessarily chalk it up to a sense of humor.

If you do a perfect simulation of an interview at home do you perform well? Find an interview question you haven't seen before, and attempt it exactly like you would at an interview. Have a software developer friend mock interview you.

If you feel like you perform better in a simulation, you may consider seeing a psychologist or reading some books on the subject. I once went to a workshop on how to deal with high pressure situations, and many of the exercises suggested made a difference to my interviewing.

The tips in the following article I feel apply equally to interviewing. I suffer the mentioned symptoms during interviews. When adrenaline levels are high the brain will enable a short-cut mechanism that allows you to make quicker decisions, but often not correct when considering a difficult question. The dreaded "tunnel vision" is a fight/flight response.

http://blog.bufferapp.com/what-happens-to-our-brains-when-we...

If you feel uncomfortable about your skills, you need to build a portfolio of projects you've worked on / created / designed... Then you can talk about those, how you designed them and why, and that can fix a poor technical interview. Those also help convey your passion.

10 rejections is insignificant, I think nobody has faced fewer rejections than that for anything, whether it's finding a job or finding funding for a startup or even finding a date.

I would need more information to know what's going wrong, but 10 rejections isn't even an indication that anything is wrong. If the technical interviews are not going well then it "could" mean: - you're not applying for the right position - you're looking for something you don't have experience in - you don't show passion or a good attitude - you seem desperate and mostly care for the money - you show a lack of interest in the company and their products

Maybe you are missing out on a lot of opportunities: - You can do freelancing - You can find a non-tech company to work for, you'd be surprised by how many need developers: hospitals, government, transportation companies, airlines, insurances, banks... Have you sent your resume to Bank of America? - You can find a startup that's in a field you kinda know and offer your help - You can talk to a staffing company, they make money by finding you a job - Go to events (eg. PHP event, Ruby on Rails, startups events, conferences...) and do networking. It's the easiest way to find a job, though you need to be good at talking to people. - Look for jobs on angel.co, monster.com, dice.com

You get to decide what to put up with in your life. You should be your biggest advocate.

Your reaction, and what you consider beneath you, is far more valuable in hiring than your performance.

The company I interviewed with is in the SAAS email space, so to get their attention I created a mini web app combining SMTP and web technologies. This took me about 3-4 hours tops. I was trying to demonstrate a few things:

1. I can code 2. I can work with technologies relevant to their company

That landed me the phone interview, which got me the on-site interview. For the on-site interview, I prepared a 1-page mini white-paper outlining some ideas I thought would be useful to their company. The idea was to show that I could bring value to the company.

I ended up getting the offer, as well as another offer using a similar technique.

Think about what the company's problems might be, how you can solve them, and how to communicate that to them. Work around your weaknesses instead of trying to brute-force it.

They also asked me lots of computer science oriented questions in the interview, and for most of them I just said, straight up, "I don't have a formal CS education, so I don't know, but here's how I think that works."

So many people try to stand out by doing some variation on the standard resume + cover letter routine, so it's relatively easy to stand out if you do literally anything else.

So as not to leave you guessing, here are the red flags that jumped out at me in the post: <em>I don't remember the particulars but I know that for every recursive form there is an iterative solution.</em> This is not a fact to be memorized and referenced, it's a consequence of a fundamental understanding of how programs execute.

<em> I still draw a blank when asked what the magnitude of complexity is for the guests function I just wrote</em> ... <em>damnit, of course calculating the permutations of a list is n-squared, but this is an interrogation of the random trivia I can manage to recall</em> This also sounds like you are trying to apply memorization to a problem that requires analysis. When asked for the complexity of a function, you don't compare it to algorithms with known complexities that you've memorized, rather, you look at the code and reason about what it is doing proportional to its inputs. There are certainly insanely hard algorithms to analyze, but I don't think we're talking about them here.

<em>I really like joint semi-lattices</em> I don't point this out to be pedantic, but as another instance of memorization vs. understanding: they are called 'join semi-lattices' ('join' one of the fundamental operations you use when working with these).

<em>I still blunder my way through an exercise to write a function which returns a boolean in response to the question of whether sequence A is a sub-sequence of sequence B</em> I ask a warmup question like this to cut the interview short if the interviewee has problems. Good programmers will absolutely get nervous, stutter, and make mistakes; that's fine; but this is simpler than that.

I once had a friend who did fantastically on Biology with little effort but did horribly on Physics, despite immense effort. After trying to help her a few times, it was clear that she was trying to apply memorization (which worked well for her in Biology) to Physics. To do well in Physics, you have feel comfortable enough with the math and physical concepts to derive your own answers. The same goes for programming and I wonder if some of your latent unhappiness with your original job wasn't caused by a fundamental impedance mismatch with your approach to programming.

I'm sorry if this was blunt; if we were in person, I'd try to be much more delicate. But you did post on HN, presumably for advice. Best of luck!

Sadly, this may be the cause more than anything else. Degrees are a very quick signal. The author may be doing as equally well as candidates with degrees, but the degree becomes a tie-breaker.

I attribute the bulk of the time to me living in a place that isn't a technical hotspot.

Personality goes a long way to getting a job, technical chops go a long way to keeping it. The hiring managers that reject you based on answering technical questions incorrectly are probably not being honest. It's an easy thing for them to fall back on when making such a difficult decision; often just saying "we don't like this guy" is difficult for HR to reconcile, especially if they interview a lot of people.

TL;DR be confident in your abilities, listen more than you talk, and learn how to ask the interviewer the right questions (known in sales as Questions that Sell). Getting any job is an exercise in marketing and sales. Getting through even the most technical interview is an exercise in sales.

The first thing that made me shock it was the questionary. The interviewer gave me a silly cuestionario and I totally denied at first: "I'm not gonna fill a questionary". I poped up my work, pointed him to my website, my github account and still, the guy wanted me to fill this questionary with silly questions, things like "what is "pixel perfect" for you" and such. He told me the questionary was made so they can "classify me" with the rest of the guys they were to interview.

Is this the level of recruiting startups want? I never had problems to recruit people. I dont need them to put stress on to solve problems in a blackboard nor tell them to solve my problem on the interview session. I really like to connect with people and see their interests, their capacity to evolve and grow, but testing skills is just silly.

>If you were to judge me just by my reading list you'd think I was university-trained but I'm not.

Would going to university make you a better developer as opposed to a 4 year version of the exercise you described? Probably not (though it wouldn't certainly drill function complexity into your head a little better). Will it make you easier to get a job? Yea, I think so. I don't know much about you, but I do know a lot of companies expect a BS. If they notice your resume doesn't list one, I would wager they spend even more time drilling on the theory side of things to validate their preconceptions that you don't know what you're doing.

Article after article says don't go to college. Sure, that's great if someone hands you $100k and you have no supervisor. But some people just want to feed their family doing what they enjoy.

Anyway, you sound like a great developer as is. And this is coming from someone who considers himself a bad developer; it says as much in my profile.

Here were my reflections on it afterwards, perhaps they may help. http://darrenkopp.com/posts/2013/04/19/Post-mortem-of-my-fai...

Maybe you could ask yourself what your definition of a 'good developer' is. I'm sure we all have our unique take on what that means. For me, communication and being able to work with others is a key part of being a good developer.

I think it's good to have a better definition of a 'good' and 'bad' developer. I don't mean the dictionary.com definition, just a definition that you are satisfied with.

From reading your article, those terms are not well-defined and the fact that you weren't hired could be reasons other than your technical proficiency.

Keep us posted my friend!

My 2 cents.

> response to the question of whether sequence A is a sub-

> sequence of sequence B.

If you can't solve this really fast it means you haven't practiced enough for the interviews.

> of course calculating the permutations of a list is n-

> squared

If I understand you correctly, it is actually n!, because there are n! permutations of n objects.

Basically, your problem seems to be lack of preparation. You study a lot but you haven't studied things that are asked in the interviews well enough.

I would recommend "Cracking the Coding Interview" book. Of course you need to actually solve problems from it. There is lots of valuable advice there. Courses on algorithms on Coursera are also pretty good.

And this is not an "esoteric question" - you should really have a good grasp on complexity in order to understand the limitations of your system, and when you can use certain algorithms/data structures, and when you can't.

See this write-up: http://www.infoarena.ro/blog/numbers-everyone-should-know - but don't memorize the numbers, that would be pointless - the idea is to get a feel of why complexity is important. (you'll notice for instance that between O(n!) and O(n^2) there is a 2-3 orders of magnitude difference in the acceptable input data size... so your confusion between factorial and n-squared is actually quite big)

I lead a team (and have lead others) that I would prefer just to fire everyone and do it myself (latest gem found today in the code: self.parent.parent.parent.parent.parent.parent, done by previous 'senior' developer).

So, if coming to Portugal not an option, interview in less tech related companies (forget SV and NY) and go for smaller ones with 1-2 developers supporting the business needs. If what you and others say about your work is right, you probably can be a good developer in those environments just not at big/hip tech ones.

I'm not going to cry about it. I am writing my own software now for myself and making money. Should have started this earlier but I didn't have the wherewithal to do so. But now I do and I'm not looking back...

Recognize that you are bad at interviewing (as I am) and strive at improving the process through choosing better suited jobs aligned with your skillset and practicing the process (which means more interviewing).

Write down immediately after interviewing your gut feelings on what you think worked and didn't work during the process and prepare for the next interview.

Get passable at that and someone will give you a job.

This could some day become a business or a side project as a hobby but for now it will give you a load of credibility when you go for interviews and will also give you the confidence that you need.

Good Luck!

I know a certain number of young women (not long out of college) whose fathers are about my age. As far as I can tell, mostly these women think well of their fathers, for all that the fathers mostly have pretty quotidian jobs. Show up, provide a sense of security, provide some discipline for the kid to push back against, and you're probably fine.

Outside of the valley a non-degree is a non-starter for many employers. Does the author even consider this?

>>And only twice have I made it past the first technical interview.

Maybe there is C-S theory the author never picked up from school and is lacking. He talks about practising programming; however, maybe his problem is not the code he knows how to write, but the code he doesn't.

Do you have a Github profile? You sound a million times better as a developer than I am, so I'm curious as to what a "bad developer"'s Github profile looks like :)

I would say 3 to 6 interviews of gradually increasing communication is a must. Otherwise you will end up misfiring a good portion of the time. If you can't do this, you should probably hire everyone on a temporary basis for a few months until you're sure they are going to fit.

It won't fix your short term financial problems, but it might be your long term salvation.

Learn iOS. Live in a tech city. Eat three meals a day.

(Which is to say, that's a comment on the market, not me.)

damn...

If that answer is "none," people aren't being honest with you and you need to find people who are.

Secondarily, are none of those people who have hired you in the past currently hiring? If they are, why aren't that asking you? May be related to point #1.

I'm exactly at the first years of my programmer career, just got my degree, and I was thinking in which I'd like to specialize and how I want to do things... but how can I succeed when all that hard work can get you to failing any way?

How about getting a "software engineer in test" role to begin with and then moving to dev role?

(I should do an AMA)

True Developer: builds technical assets (apps, scripts) based on business needs, often by self-initiated awareness of what the company's needs are.

Corporate Developer: turns managerial ideas (with no audit of whether those are good ideas) into apps that sorta work, very quickly, with a smile on his face.

True Engineer: focuses on infrastructural concerns, performance, debugging and monitoring, and maintenance. Writes solid code with good tests and, usually, high-quality documentation.

Corporate Engineer: bike-sheds the hell out of technical choices (war of attrition, and managerial favor helps) so he controls the stack and becomes the "blazer" while the other N-1 spend most of their time keeping up with his changes and look like underperformers. Calls himself an "architect".

True Programmer: writes excellent code to solve problems. Enjoys writing code, perhaps a little bit too much. Constantly learning new languages and technologies. Cares more about the technical challenge than the macroscopics of the problem (unlike the developer, whose stance is the reverse).

Corporate Programmer: drags windows and highlights stuff on his IDE. Moves the mouse around in circles for 8 hours per day, then goes home at 5:01. Occasionally plays with the menus and something "magical" happens, like the auto-generation of 18 Perforce clients due to some bizarre interaction of IDE plugins.

OP sounds terrible at interviewing and is probably really bad at Corporate, too.

He could get good at interviewing with a month of practice. I could coach him on that. Being good at Corporate is not something I'd be qualified to teach, and I'm not sure if it's desirable in the long-term (although it is convenient in the short term).

Also, from the companies perspective, if you can't even accept their interview process. How on earth are you going to accept all of their other wacky corporate rules you will have to comply with day-by-day. On your first day you will probably be like "I have to put my opening brackets WHERE? Dude, that's sick..." or "I can dig the spinning in my seat three times before committing code, but why the hell can't I commit when the line count of the commit is negative?"

You will not make a good corporate slave.

Will be nice if you write something on that. Will be beneficial to many people.

This hit home... I wish to change it though.

That of course could be the case, but I've built a vision of this guy in my mind after reading his diatribe (against himself). He's clearly just incredibly insecure, frustrated, and possibly self-loathing because of it. It's possible he had/has an axe to grind and nowhere to grind it so he just comes off like an ass. When people get like that, it's almost as if they put off an aura of failure as soon as they open their mouths. After reading his post, it's no surprise this guy doesn't do well interviewing. If your friends -- who are developers -- are telling you in no uncertain terms that you're not a bad developer, and you don't believe them such that your next step is to then seek the validation of complete strangers on the internet, there's obviously something much bigger working against you (in concert with lack of confidence). Perhaps he has very poor hygiene -- or, as you mentioned, poor social skills -- or something else that makes a horrible first impression. First impressions are everything, and this guy clearly isn't making a good one. Then again, maybe it really is the case that he's a bad developer with shitty friends.

Having faced seemingly insurmountable obstacles that involved my nearly getting killed for years on end (and a divorce, and death of friends, and what amounts to enormously difficult daily hard labor), I have ZERO sympathy for this kind of crap. Can't find a job after your little vacation? Boo hoo. At least you have all your limbs, can go to the market without getting shot at, and your wife and daughter haven't been executed.