I Am a Bad Developer | Hacker News Reader

I Am a Bad Developer

eewz0z.pen.io

299 pointsaccutrements204 comments

On Friday I had a remote interview where I was asked to search for the value closest to X in a sorted 2D array (columns and rows are both sorted in increasing order). I came up with a trivial solution to find a specific value, but got tripped up modifying it to find an unknown value that could be higher or lower than the target. I have not heard back from the company.

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.

Ya, I've been the victim of "couldn't balance a B-Tree fast enough so you're not hired but you'll never see a B-Tree at work."

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.

Github and many other high profile companies have the benefit of a much larger talent funnel than more average companies. They can literally sit back and wait for the proverbial rock-star ninja to make a passionate appeal to come and work for them. They can filter anyone without a 4.0 from a top school (not that they would, but that's not the point) and still be working with a bigger pool than lesser companies do, pre-filtering. Never mind actually selling yourself so those you might want to hire will actually accept your offer.

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.

True, they have a bigger talent funnel than smaller companies, but don't forget that they also need far more new hires than smaller companies. I wonder which factor dominates.

I didn't say "small", I said "lesser".

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.

What make you think GitHub haven't fired anybody? I don't know that they have, but it seems very unlikely.

In fact, they have fired a few people.

Holman has in the past made the claim that nobody's quit. I wonder if that still holds up?

Ya, I got my info from Holman. My info's old.

A friend of a friend was recently fired from Github. I don't know where you got this information from.

Or is the hiring practice of reducing someone's technical competence to a handful of esoteric questions arbitrary and broken

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

I look for relevant experience, personality, and problem solving skills. I start off with questions that'll get me an insight into the person then I give them a written problem that'll take them 10+ minutes to answer. I want to see them work through it, see what they get stuck on, see when they ask questions and what questions they ask. I ignore syntax errors, and similar minutiae. If you don't have good problem solving skills I don't see how you can be a useful member of my team.

First, congratulations. Good luck wherever you choose to go.

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.)

Also, it goes the other way: A senior engineer will be a lot more picky, and take more care to scope out good places with hard problems: The places that have higher bars for hiring.

My uncle is a senior marketing executive and I can confirm that whenever he conducts a job search it is an epic undertaking. So this tends to be true in many industries, not just software engineering.

> Or is the hiring practice of reducing someone's technical competence to a handful of esoteric questions arbitrary and broken?

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.

Did interviews for 5+ years at Google... the real problem is that there's no uniformity to the hiring process. I was allowed to just make up my own questions and judge candidates based on those. And I did so. And admittedly, the questions I asked were so difficult that I seriously doubt I myself could've answered them when I first got hired.

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.

Wow, glad I've never been interviewed by you.

> And admittedly, the questions I asked were so difficult that I seriously doubt I myself could've answered them when I first got hired.

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

No, but I would like to hastily assure you that it is solely because I am a coward when it comes to NDA issues.

> And admittedly, the questions I asked were so difficult that I seriously doubt I myself could've answered them when I first got hired

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.

There are some problems with the trial period. It doesn't account for those that don't have specific domain knowledge. From my experience, I have worked with people that have hit the ground running and been really productive straight away, but in the long run have not been as innovative as others.

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.

I think your onto something.

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.

> I love the idea of a paid working trial of some length

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.

I've seen six months work - that's time enough to ramp up somewhat and deliver. In that regard, it's plenty of time to assess the traits that we're looking for in strong developers.

Do you get back to them with the decision well before the end of the period, though, or do you just leave them without an income at the end of it if you decide you don't want to hire them?

That is the usual practice in countries like France, where new hires are on a trial basis for a period of one to six months (all other things being equal, the trial period only means that both the employee and the employer may terminate the contract at the end of the period with minimal administrative fuss).

There's a brilliant algorithm. In the interest of looking good for promotion, waste everybody's time, miss out on the good people that would help the company succeed (and presumably that would grow the stock valuation), and, the good interview candidates miss out on a job that feeds them and helps them grow their career. Just brilliant.

The problem is a bad metric of evaluation (if not doing interviews actually looks bad at promotion time). I'd suggest that the fact that some people can look at themselves in the mirror in the morning with statisfaction while screwing over both their employer and prospective employees is also a problem.

People really need to stop lumping fizzbuzz into their hatred of "trivia" questions. You don't do variations of fizzbuzz. Fizzbuzz is not a challenge, it is not trivia, it is not a trick question or a brain teaser. It is the simplest, most inane function you can ask someone to write. It exists purely to filter out people who simply can not write any code at all. It is a test of "does this person understand the concept of a loop, and the concept of a conditional". That is it.

I agree that Fizzbuzz isn't a trick question or a brain teaser. If I disagree with you about "trivia", I think it's because I disagree what the word "trivia" means, not because I disagree about Fizzbuzz. Whatever.

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.

>However, I do meaningfully disagree about "variations of Fizzbuzz".

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.

Confirmed. I give interviews and people get offers or not based on my feedback. I also don't know what I'm doing. It could be Imposter's Syndrome or maybe that's just what imposters tell themselves.

I had a similar experience. I was asked to do some coding, got hung up on one of the questions.

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.

I saw your hack at AngelHack SF. It was a great product and I was surprise that you did not get the grand prize.

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.

Thanks! I am still working on Coderang (the version I showed yesterday is up at http://coderang.com), and I think I could definitely turn it into a business.

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. :)

Great. contact me at doanhqdo at berkeley.edu if you want some free business advice. I am currently working on a start-up that is being incubated out of the UC Berkeley's Skydeck incubator. I should be able to connect you with some people if you'd like.

Isn't the author just experiencing imposter syndrome? http://en.wikipedia.org/wiki/Impostor_syndrome

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?

Granted 10 is a bit much. But it depends on who to interview with. If you are good, there are consulting companies like ThoughtBot or PivotalLabs who hire good developers pretty easily. And their interview process is all about checking if you are good and get along with people rather than just if you know how to traverse obscure data structures.

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

I think it's a combination of both. He sounds ashamed to be a software developer to the extent that he doesn't want his daughter to know. What's up with that? It might not be the same as being a heart surgeon, but at least in the US software engineering is viewed very positively as a career, probably alongside chemical engineering and law (actually law is viewed fairly negatively by many these days).

Ever heard of a heart surgeon that can't pay his bills?

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.

Heart surgeon? No. But lawyer? Yes. Chemical engineer? Yes. Physician? Yes (private family practice is a dying art in the US). Movie star? Yes.

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.

> 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.

When I hit the "I allowed one month for interviewing and one month for buffer", I already knew what the outcome would be and my brain was screaming "WRONG!"

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.

Anecdotally I have come across developers that match the description the OP gives of himself. They read a lot of papers, they know a lot about the inner workings of many common and obscure programming languages. Many know and love development process theory and they contribute to open source projects. Here is the but: when push comes to shove, they can't deliver to production.

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.

Tend to agree (though it's impossible to say about any particular person.) Mentioning TAOCP and SICP at an interview (as he did in the post) would raise some alarms with me. They're not useful books in most jobs, and bringing them up just makes you look like the kind of person who doesn't understand that.

I see it from another perspective: Mentioning that kind of stuff suggests an appreciation for the finer points of the trade. No, I don't want to work with people who are all theory and no practice. But I do want to work with people who treat coding as more than "copy and paste from Stack Overflow until my boss tells me I'm done."

Steve Yegge calls it "The Awful Place Where People Make Money With Software"

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

Wow, I forgot how horrible he was. How can someone spend that many words just to cough up a few awful strawmen, and then not even bother to knock them down?

> They're not useful books in most jobs, and bringing them up just makes you look like the kind of person who doesn't understand that.

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.

Yes, surely we wizards have no desire to leave our big dinners and comfy armchairs at the Unseen University to do any actual magic.

>They're not useful books in most jobs

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.

It's clear that the author is very motivated and probably pretty smart, but I wonder if there might be some gaps in his knowledge foundation. I was surprised for example that he was learning about information theory, and yet he had trouble analyzing the computational complexity of a function that he coded.

Not sure if that's really relevant. Unless you are applying for a job where time is money stock trading or some such I don't see how knowing a method you are writing is O(log N) rather then O(N2) is useful. Its something to keep in mind sure, but I would rather have the slower method integrated into the code base faster.

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.

Knowing the time complexity a given function you write is generally not important. However, the skill to analyze the complexity is an important one to have, because when performance issues to come up, it is often a very powerful tool to have.

Agreed. However it would probably be better to show someone some code with a loop in a loop and ask them why it could potentially be a problem.

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.

Right -- Big O notation is a useful formalization of a thinking process that in practice usually includes more information.

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.

My read was that he froze during the interview. Perhaps I was injecting my own experience, which once very literally went like this :

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.

I'm drawn to this for several reasons...

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.

You should probably read up on why this is, in fact, important before your next interview. Just a free piece of advice.

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)

I understand Big O.

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.

You're right that it matters very little if you can deduce the exact complexity right off the bat. But it DOES matter is if you can tell if an algorithm is closer to n^2 than log n. OR identify that n is low enough that it doesn't matter.

> 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.

Going to have to ask for an example.

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.

What does "poor queries" mean other than queries with poor asymptotic complexity based on the query plan?

Doing something like the following would classify as a poor query in my book with a very simple query plan,

select * from table;

The query plan for that is simple, but the number of bytes transmitted per query is O(size of table) (as is the disk IO on the DB), which should clearly set off a red flag if you know that size of table can get large. You don't need a large exponent; You need to understand the rough cardinality of values, then you need to look at asymptotic complexity.

So, the problem with your exclusion of "non-simple CRUD apps" is that simple CRUD apps have a nasty habit of ceasing to be simple.

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.

A very easy, common example: given two lists of objects (from a database most likely), find the set of objects contained in both lists. The naive solution is a double for loop over each collection.

If you put an O(N^2) algorithm in production, you'll kill whatever relies on it. If that's our funnel, we're out of business. If its our DB, it'll go on fire. Not being able to reason about complexity is a no-hire for me.

That's only for cases of N over some value. An O(N^2) algorithm over a list of 10 is not going to break anything.

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.

Shouldn't it be OK to have a knowledge of programming that doesn't derive from the theoretical canon? You can learn programming concepts in the context of "not killing the whatever-is-relying-on-it."

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.

Big-O notation takes five minutes to comprehend. I don't see the problem.

I'll take that as a "no."

Although understanding the difference is important, the specifics are typically far more relevant in a high performance language than a dynamic scripting language with lots of "magic". OP is interviewing for a C++ gig, so performance was clearly a motivating factor.

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

For a C++ I agree hence I mentioned it being important for certain cases, but for something like your standard CRUD app its probably not worth thinking about.

Once I made a Ruby program noticably slow by using "array += items" instead of "array.push *items" in a loop, making it O(n^2) instead of O(n). Once we noted that doubling the input size quadrupled the runtime, I found the bug. (I was a Ruby newbie and didn't know that Ruby's "array += items" is just syntactic sugar for "array = array + items".)

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.

Oh shoot. I used array = [array, other_array].flatten to get around the += slowness. Way faster on lists of tens of thsouands that I was throwing around. Totally forgot push. (Granted, my solution was developed on Sunday morning with a hard deadline of Monday morning and I had been working hard all week. )

The real value of someone being able to respond on the time-complexity of a given arbitrary function is that it shows they can build a good mental model of what goes one when the function is run. Building a good mental model of a program is the most important thing when designing it, building int, extending it, or fixing it. So it's not about performance - it's about understanding and abstraction skills. All good things to test for in an interview.

I find it comforting that a coworker isn't going to unknowingly hide lots of superlinear algorithms in the codebase that will blow up without warning when data sets get significantly larger than the test data.

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.

The fact that someone can tell you what the big O of an algorithm is wont prevent that though. You would be better off following a decent peer review process and performance profiling the application.

It's not an either-or. Competent developers and teams can do both.

I know a specific case where a manager was convinced he could do a better job of something than his employee, and coded up an algorithm over the weekend that performed 20% better on the test-data and was only slightly slower.

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 actually don't think any of this is relevant to the OP's situation, as by his own admission his interviews never progressed to any sort of production-level problems. He was just given algorithmic puzzles to solve.

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.

In paragraph 6 and 7 you reject that it's a case of being bad at interview - but then in paragraph 15:

> 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".

This comment really lit a a lightbulb on me. I also know that I'm a good developer and I've learned a lot of technologies, helped out Open Source software projects and lots more, but I recently realized that I suck at interviews. I've been interviewed (at least remotely) on every company I was interested in and nearly made it.

I really have to work on this.

You had some money, and you didn't feel "fulfilled", so you took a break for a few months? And all the comments are about how poorly designed the interview process is.. The thing I want everyone to take away is "don't gamble with your fucking income."

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.

Living in a permanent fear of being jobless could be quite harmful in the long run...

Please explain your assertion? Unless you're talking psychology, in which case please don't bother.

Out of fear you might not dare choosing a more rewarding path/job. Should be obvious?

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

I definitely do not oppose finding a new job, only quitting your old one first, which seems to be a mistake that everyone makes at most once.

All I would say is, aim much lower, pick up plain old ugly Java, learn Spring, Hibernate. From being a "bad" advanced algorithms Lisp / C++ developer it's an easy jump to be an "ok" CRUD apps developer / Enterprise drone. You will nail the technical interviews, just try not to be overqualified.

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...

Here in Australia, I'd say go learn C# and do CRUD - but then again I'm sitting in Canberra and the feds love Microsoft tech (admittedly, I do love C#)

Java seems to be on its way out here.

Being rejected repeatedly is disheartening for sure. However, 10 rejections is actually not that many, nor is two months a very long job search. Many companies have a pretty narrow idea of what a good candidate is - e.g. "5 years experience with X" or "agrees with the lead engineer about most things" or "can solve this tricky puzzle". I'm a very good developer and have a degree from a top school but faced many rejections early in my career (more than 10 I'm sure).

Maybe you are applying to the wrong places? I work in Silicon Valley and without naming names I can say I know there are places that will settle for very mediocre technical talent because it is so hard to get people right now. Avoid the well known, "hot" companies, and the start ups. Look for big companies in hot job markets.

Could you give some examples?

Go on Dice, then search for any job listing requiring J2EE/struts/hibernate. The technical interview will consist of explaining what polymorphism is and a handful of OO design patterns like singletons and factories. Then give a poignant speech about the evils of multiple inheritance, why interfaces are better, why you love XML, why writing SQL statements in the code is wrong and the only way to talk to a DB is with ORM, and you are done.

Why is the only way to talk to a DB with an ORM? Why cant you have SQL in the code? Sounds like you think the only way to write well structured and clean code is by introducing more layers of complexity?

I don't think those are the GP's thoughts; rather the GP is saying that if you say that you have those beliefs you have a good chance of getting hired at those companies.

My dear, the parent was slightly sarcastic. But he is right, that in order to please the corporate ears, you need to sing the 'right song'. You get hired in no time. Learn the corporate buzz words, etc. Once in, you will meet some saner persons, which do the right job, so that you will not feel to be in some mental institution, where all speak some acronym gibberish.

Oh, the job search. The sobering discovery that most companies are looking for cogs, and you don't quite fit on any of their axles. I've been through this several times. Here's my recent experience:

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.

This might be unpopular, but you don't sound like a bad developer, you sound like you're lazy.

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.

I'm looking for work and this is kind of driving me up the wall too. Not so much the algorithm stuff (generally I can crush that, even if I see the point the author is making). It's the take-home stuff.

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).

I don't understand how one can draw that conclusion from that dataset. Getting turned down during the hiring process says absolutely nothing about your ability to develop software because job hunting isn't a software development activity.

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.

OP here.

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'm a lot like you, so I hope you'll believe me when I say your entire problem is that you allocated 1/4th the time you needed for getting a new job.

I think I went through 50-75+ different applications, 25+ phone/skype screens, and 5 on-sites for my most recent job hunt. I stopped keeping track after a while.

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.

I can't speak for the OP, but living in the boonies is great. It does ensure a long time between jobs, and the choices aren't as good. On the other hand, they tend to really value you since it's just as hard to get people to move to the middle of nowhere for a job as it is to find work out there. Scarcity works both ways.

No sympathy here. "I am a bad developer"... so? At least you have recognition of a problem, now time to improve.

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.

How about a link to the contributions? Perhaps you can get some better feedback from people looking at those.

  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.

Why the blundering? It's not a memorization exercise, it's an exercise in counting and math:

  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 think most good interviewers will be ecstatic if you can reason your algorithm out loud, even if you're a little off. It's the reasoning and thinking that matters more.

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.

Yes, I found it a bit odd too that the OP claims interest in math yet seems to have problems understanding computational complexity. Although, mathematics is a very broad subject, maybe his focus was on something else.

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

Actually, it's still O(N).

Yes. But O(2N) = O(N) :D

While you (the author) might be having trouble job-seeking, it turns out that employers are terrible at hiring. There is a lot of lip service to hiring and hiring struggles but very, very few companies take it seriously. It's not perceived as a core business competency so you end up going through a lot of subjective and ad hoc processes.

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?

I just turned someone down today who was by all accounts competent, but just came across as the kind of person I wouldn't want to work with.

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 think the guy was just being honest. I've never been in his situation before, as I subscribe to the notion of not leaving an opportunity until you have another sure fire opportunity (I know this isn't a popular outlook here), but I bet he's scared and just did a brain dump of his feelings.

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've never been in his situation before, as I subscribe to the notion of not leaving an opportunity until you have another sure fire opportunity

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.

The issue I have with places that expect you to write functions and solve complex problems off of the top of your head is that they prove nothing. You might be able to write a complex sorting algorithm but you might also struggle to work under pressure, you might struggle at coming up with solutions for simple problems by overcomplicating things and taking longer which in turn yields a more complex and working end-result but cost the company twice the amount of money it should have.

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.

You seem so obsessed with being part of the true programming elite. And blow it up so far as to think that most people know how to answer those interview questions.

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.

Ask. For. Feedback.

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.

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

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.

The company will generate a very small amount of good will (maybe) by giving feedback, against the very scary chance of a lawsuit.

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

No point usually, any company large enough to have HR isn't allowed to answer that. Frustrating, because I'm not going to sue you, I just want to know if there is something I need to work on.

I wonder what would happen if programmers started questioning the types of interview questions that they received (especially when they don't relate to the job in any way)?

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.

Was hoping to empathize with the author, but just got annoyed by the end. It felt almost like emotional extortion, especially ending with the daughter bit.

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.

After reading your list of professional habits--writing tests, contributing to open source, reading lots of technical literature--I think you're head and shoulders above a lot of employed programmers. I've been the technical interviewer before, and if you told me all that, I'd recommend hiring you, assuming you have a reasonable background. It sounds like you have a real appreciation for craftsmanship, which far too many programmers lack.

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.

Without any exposure to your code or you personally, my guess is that you're far from a bad software developer and unlikely to be inherently bad at interviews. However, only planning 2 months for a job search means you're bad at managing your career. It can take that long to get the paperwork pushed through even once you have found a job!

Maybe it's me, or my non CS background, but I feel that many positions could be filled by a "normal" programmer that doesn't spend nights coding esoteric algorithms. On the other hand, the esoteric algos guy might get bored in a job that seems requires routines (bug fixes, testing, coding boring interfaces, etc.) and might not play that well in a team.

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 could have written this piece. It hit that close to home. I'm 15 years into my IT career and I can honestly say it's not getting easier. I don't believe it's an ageism thing, but just a symtom of something I still cannot put my finger on.

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.

Only after answering all of the questions in the phone interview properly, only then will I invite them in for an in-person interview. However, even an in-person interview doesn't contain stupid programming puzzles or tricks...merely practical examples of things that have happened on the job.

[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

100% agree.

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...

Absolutely the best questions to ask in interviews, in my opinion, are open-ended questions. The problem with those, however, is that the interviewer himself has to know enough to be able to correctly judge whether the candidate's answer is a reasonable one.

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've had some good luck with open-ended questions like "Tell me about a time when you had to deal with a scaling issue." How they define "scaling issue" often says just as much as their explanation as to how they solved it.

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!

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...

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".

What happens when you enter a URL is just a specific implementation too. It's going to differ between operating systems, browsers, network setups..

I find this amusing because I went through this same ordeal last week. The problem was to code up a small interpreter. The interviewer seemed to be suffering from either a cold or allergy based upon the constant sniffling. Anyway, here I am explaining how I would go about it and there seemed to be a sense of irritability from the interviewer. As I try to figure it out, he somewhat guides me to the solution. In the end, I worked it out with his guidance but the obvious frustration and my three cups of coffee had me a bit uneasy during the process. He ended it with a "thanks...good luck" <click> On reflecting the interview, my thoughts were "after coding for almost 12 years, what is going on?" I want to know the validity in these problems in regards to hiring. I never put any interviewees through this. My goal when interviewing people is to have a conversation to discuss how they think, how passionate they are in their work, get an idea of their personality, and, most of all, do they know enough to do take on the job they will fulfill. This all revolves around the relevant technologies they claim to know. As I am a few years to 40, my worries are getting worse about where I will be in the future. I am slowly accepting the idea that project management will be my next destination.

"My goal when interviewing people is to have a conversation to discuss how they think, how passionate they are in their work, get an idea of their personality, and, most of all, do they know enough to do take on the job they will fulfill." Thumbs up. I follow similar principles when taking interviews and always believed that to be correct

> - 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.

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."

I used to like this question, until I interviewed a few people who hadn't worked with HTTP. Then it's unclear how to rate them. Since I'm not interviewing specifically for a web programmer I had to pick problems someone could work on without that kind of experience.

Could you maybe explain what it does at a high level and get them to maybe explain how they think it might work? It would probably be just as informative.

Objection, your honor: relevance.

Those "stupid programming puzzles" are about evaluating problem-solving abilities. Asking about architecting a system from a higher level also does this. Asking how a browser works is in the memorization category, and I just don't understand how that can give you useful information.

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.

To answer how to get an URL in detail would need understanding of the 7 layers of OSI, sockets, http/ftp/etc, SSL, html layout, keepalive, etc etc. The answer should be a really informative about how much someone understand (and check architecture grokking). [Edit: I might try this, thanks!]

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

On the other hand, it's a good question to see how someone handles limited or lacking knowledge, because knowing everything about an HTTP request down to the wire is hard. There is just so much going on in that stack by now.

true, it is not about programming, but how much programming does a programmer do? this is over a phone interview and I hate asking actual "type this code" in phone interviews. The way I view this question is the way I view, say, a carpenter. A carpenter must know the different types of wood, the milling technique, etc. Of course, they don't need to know it to any great extent, but have a rough idea because in the course of their work they might come across something new to them, and need to rely on the fundamentals.

>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

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.

Heh. Yeah I do ask it in that way and I've had a couple interviewees be cheeky and go right down to electrical signals. That's when I can see they have a bit of a sense of humour and aren't nervous. It also breaks the ice. However, I typically interrupt them and go as low as DNS routing packets and its ilk.

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

The problem is that the question is so vague as to put an interviewee on the defensive, requiring that they go down to as deep a level as possible and adding to the stress of the situation. Not to mention that the last time I saw that question in an interview it was on a written quiz that appeared to be xeroxed from a daisy-wheel printed page.

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.

As far as the integer intersection question goes, I wonder if the interviewer didn't think too hard before before saying that he never uses it. At least where I work it comes up from time-to-time.

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 can't really make a guess about the author's coding abilities, but all the evidence in this piece suggests a severe lack of confidence which is probably immediately apparent to prospective employers.

I think it's hard for some to show confidence after being rejected a bunch. That may be coming through in the writing because of the recent rejections.

I perform much better at interviews when I am relaxed. If you put too much pressure on yourself, then you will not be relaxed and will perform badly.

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...

I think your inability to find a developer position has nothing to do with your ability to develop. I recruit for my company and the most important is how you sell yourself. Every company looks for a very specific profile that fits.

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

At a job interview, after shaking hands, say to the interviewer "Before we start, I would like to ask you a question, would that be OK?" If s/he says "no", leave. If "yes", then ask "as part of your interview will you be asking me to solve tricky problems on the spot?" and if they respond "yes", then leave.

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

The problem is that life is full of what looks like trivial tricky problems.

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

I also feel like I'm not very good at in-person interviews because I'm not very good on-the-spot. I mitigated this by using a variation of "The Briefcase Technique" which I learned from Ramit Sethi.

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.

Great strategy!

I got my last two jobs this way minus the white paper. For the last one I learned Rails and made an app using the technologies listed in the job description, threw it up on Github, spent a lot of time on the cover letter, and voila.

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.

After calling yourself a "bad developer", I was hoping to find a link to your github so I could judge for myself. I'm not implying my judgement matters; I'm just curious.

I'm pretty sure it's an anonymous post .. on purpose.

From your post you sound like a nice fellow and I wish you the best and want you to find happiness and job security. However, also based on your post, I am sad to say that I think you're right, you are a bad developer. I strongly urge you to lower your sights and aim for a job that has a lower skill requirement.

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

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 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.

I really like joint semi-lattices 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).

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 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!

> by my reading list you'd think I was university-trained but I'm not.

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.

It is extremely disheartening to go through rejection after rejection but you have to do your best to not let it get you down. You certainly dont sound like a "bad developer" - its just that the market is tough out there and companies can pick and choose. I have "failed" many interviews and I know it can knock you around. Its only a matter of time before you find the right job - not saying you might not have to take a more menial job in the mean time to keep the money coming in. I was unemployed at the beginning of the year - I was lucky I found another job after three months.

I interviewed for nine months before I got an offer, and I have a coupla years experience and a few hot techs going for me.

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

It isn't the technical skills that are lacking, it is confidence and the ability to sell yourself. If you have the experience and code samples, you can still get technical questions wrong, so long as you're able to admit defeat in a confident, intelligent way. You're not asked esoteric CS questions to see if you understand CS, you're asked them to demonstrate your critical thinking skills, ability to communicate, ability to ask smart questions, and, most important of all, ability to ask for help when needed.

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.

2 months ago I went to an interview for a hot startup here in Spain. They just were looking for an IA who can code frontend languages so even I'm working i decided to give them a shot and went to their interview.

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.

I can't believe no one commented on this gem:

>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.

Same thing happened to me recently. I don't know what I would do if it happened to me 10 times, but I may find out soon enough.

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

I'm interested to understand your definition of 'bad developer'. It seems, from reading the article, that your definition of a 'bad developer' is someone who cannot get hired (Please correct me if I'm mistaken).

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.

I once had an interview in which I solved the entire esoteric question with relative ease, and then proceeded to entirely forget how Ruby's block syntax worked. Literally couldn't figure out how to use max_by. The dear in the headlights syndrome happens to a lot of us, and when it does, it really makes you feel stupid. Trust me, you're not the first person in those shoes. You WILL find a job, and over time your confidence will be renewed. In the mean time, why don't you take some contract work? There are always just-starting companies out there who barely even know what they're looking for. I can almost guarantee you'd be able to be of service to them.

Keep us posted my friend!

A lot of this angst can be resolved by just buckling down and working through a good algorithms/datastructures book, chapter exercises and all. Yes algorithm puzzles are over used in interviews, but if the game is played that way, learn to play it.

My 2 cents.

> 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.

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.

This. I can't believe nobody else pointed out that it's not n-squared. (but, lots of people pointed out that complexity is really about reasoning not about memorisation - and you have to be good at reasoning in order to be a good programmer).

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 think programmer interviews are really getting ridiculous. We don't ask doctors to remember details from organic chemistry during an interview. We don't ask plumbers what toilets they've unclogged in their own side projects.

Come to Portugal. We like bad coders here. Seriously. 99% chance you won't have a technical interview.

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 am NOT a bad developer. I have a resume that just kills. 15 years of experience. But, I am 52 years old now and basically have been thrown out with the garbage. Why hire me when you can hire a 25 year old that can crank out code way faster and is willing to work much longer hours than I am. All I can say to the hiring managers I've interviewed with recently is fuck you.

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...

Personally I am very proud of the community support shown here on HN to the OP’s post. I saw it earlier today and didn’t have time to respond so I up voted it just before it slid off the new posts fold hoping it would make it the FP.

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.

IMHO, little that you mention, the books, the open source projects, the magnitudes of complexity, the math, code-kata, the introspection, whatever, has much to do with what people need to develop software. What you need to be able to do is take crazy shit thought up by management, clients, contractors, government, and turn it into good enough software. The job is to appease those who are paying and attempt to squeeze as much good code into it as they can tolerate.

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

Can I please request someone here to offer this man a job? He's onto his last buffer month. He has a daughter, he's desperate & contrary to what he may believe, he IS a good developer. And yeah, please have a broad smile when you have him over. He probably needs it most right now. I'm sorry, but that was too depressing to read. We've all been through this stage of self-doubt and agony. But as they say "This too shall pass" and sooner or later he'll be kicking ass! :)

This man has a wife and kids and even though I feel for him you can't just quit your job when you have a family that relies on you. I wish him luck but there are people much worse off than this individual.

Have you considered putting yourself out there. What I mean is that have some project that you can show as your own work. With your name on it. Work hard towards making that successful. Be it an app, a website, an open-source project, it has to be recognized as primarily your development work.

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!

Four months and 10 interviews does not sound like that much. It is unfortunate that he is looking at strained finances.

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.

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

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.

I agree with other people who say that it wasn't the best idea to take 2 months off. At the very least, you must know that a gap in your resume must look bad to recruiters. Might've been better to get a new job offer and tell them you needed a week or 2 before you could join them.

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 :)

If you want to stay anonymous, DM me @jogjayr

If you want to run a company with quality people (and not just employees) you have to spend more time hiring each person than 30 minutes.

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.

You are twice as good as I am. And you have put something in words I would never ever have dared to, or am capable of. I see you as a bright individual. I am struggling with the same question. With 7 years of experience and not good enough open source code to show, I am spiraling in a vicious circle. I love Math, programming and physics. Thanks for posting, you glorious dude.

If you don't fit into someone else's box, create your own.

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

Something has to drive us to get better isn't it? Everybody who is anybody goes through similar pain. The only way to get out of that feeling (IMHO) is to concentrate on what you are accomplishing everyday (as opposed to learning) that is of help to yourself and others, and then look for satisfaction from within not from others' opinion/judgment.

Only 10 applications? How many applications do y'all typically apply before accepting an offer? I've been told around 40.

Well, I did four last time ... and selected from four offers.

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.)

>Eat three meals a day

damn...

To the OP: What negative feedback have you received? What have people told you you need to improve?

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 don't get it. And it get's me worried.

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?

>>>At many organizations I've worked at I championed automated testing

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

This does hit close to home, I'm a great programmer but I get so nervous in interviews that half the time I can't do fizzbuzz :-(.

(I should do an AMA)

Being a good programmer is not the same thing as being a good engineer or developer. Also, there are the true and corporate varieties of each.

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).

Your description of corporate programmer made me laugh.

>>I could coach him on that.

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

In half a year the Corporate Developer will still have a job because he knows how to build "apps that sorta work, very quickly" while the True Developer spent most of that time developing his own dialect of Lisp and his team never shipped a product.

I agree it seems OP is bad at interviewing, as well as some others who have replied to OP. It would be better to view the interviewing process as a game with a weird set of rules, half of which you don't even know when you join the game. Realize your chances of winning the game (i.e. getting the job) are generally not increased by ferociously attacking the rule book.

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.

" I never achieved much and there's nothing I have done that I'm especially proud of. I just got by as best I could even when the world decided I wasn't good enough anymore."

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

First world problems. Amirite? :)

Word!

I guess people aren't too happy that I dislike thinly veiled attempts at trolling for a job on HN, wherein the author has failed to plan properly for a four month vacation ("sabbatical") and thus requires validation from complete strangers. It's pretty clear here that OP wasn't affected at all by the recent recession if he's complaining about not being able to find a job after only a month and a half. OP clearly needs to burn off his baby fat, and it's likely that this situation might be just what he needs to grow up.

Regardless of OP's actual intent it definitely is a first world problem. I'm sure OP is smart and a capable programmer but I also wonder, he did say he's 10 years into programming. If it's not that he's a bad programmer, or that his social skills are not lacking, maybe ageism could be an issue?

Interesting observation, about ageism.

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.

Reply on news.ycombinator.com