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.
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.
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 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.
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#)
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?
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.
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!
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.
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 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
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).
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."
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, 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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).
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).
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.
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 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.
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.
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.
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 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.
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?
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.
222 comments
[ 3.1 ms ] story [ 277 ms ] threadPick up either Spring/Java/Hibernate for the corporate "boring" market (but still well paid / plenty of offering) Or Rails / Django for the still cool startup market
You can make a good living as a CRUD app developer, many of us do just that. reading through SICP is a huge bonus, but not a requirement to get a job in this "improving, but not yet fully ready for functional programming" world.
Did you ask yourself sometimes if you are perhaps overqualified? or causing the impression that you are going to over complicate things? Did it occur to you that you are maybe making interviewers look stupid as you give them a functional solution you learned in SICP to a problem they had in mind a imperative, for loop, lot's of shared state solution to? Perhaps you are too good of a developer for your own good?
I interviewed and hired lot's of developers, and having someone "too smart" is sometimes as bad as having someone who is, well, the opposite...
Try to go to a professional mock interviews service, and check if it's indeed you being a bad developer or something else, check anything, gee, check even your breath, (not kidding, had candidates who were brilliant but simply had bad breath, I was the only one decent enough to tell them that I guess as they didn't understand why they can't seem to get a job) not that I'm saying that this is your problem, but don't go and say that you being a bad programmer is the reason without very serious investigation.
Take it as a debugging task, rule out anything, I'm pretty sure you are a developer much better than many others happily employed that the moment...
Java seems to be on its way out here.
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?
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.
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.
I attribute the bulk of the time to me living in a place that isn't a technical hotspot.
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
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?
Imposter syndrome does sound quite right. Or the guy is just depressed pretty hard.
Now have you heard of a developer that couldn't pay his bills?
That's why he wouldn't want his daughter to know what he does.
Very few career paths offer absolute job stability and an infallible guarantee of employability. That's no reason to be embarrassed of a career choice.
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.
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.
Learn iOS. Live in a tech city. Eat three meals a day.
(Which is to say, that's a comment on the market, not me.)
damn...
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.
http://steve-yegge.blogspot.com/2007/06/rich-programmer-food...
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, I would certainly question their relevance to most jobs. But we're not talking about most jobs, we're talking specifically about software development jobs. Where they are incredibly useful.
Yes performance is a feature but realistically you can get away with some fairly awfully performing code for a long time in most situations.
I remember a conversation a while ago where people we asking if you could have a language that offered X increase in performance over C for X increase in processing time what value of X would you pick? In most cases people are willing to trade a lot of performance for a lot of productivity.
If they can tell you in Big O notation why its bad for large inputs then great, but so long as they can tell you why that's what really matters.
That is -- anytime you write a loop, you'd better think about what's inside it (and how long those things will take), and -- given the amount of data you might be sending through that loop -- if that's a problem or not.
I want someone to notice that they're making a remote call in a loop when it could be batched, cached, etc.. I don't want them to spend 2 days optimizing an algorithm tinkering with a bit of text that yes, is inefficient, but in practice is only going to take a few milliseconds anyway and isn't a hotspot.
interviewer : "what's the time complexity of blah"
me : "hmm... O(1)"
interviewer : "what's the space complexity?"
me : "fuck, oh, I don't know"
interviewer : "well, think about it. no stress"
me (2 seconds later) : "oh, right, yeah, O(n)... of course"
Not saying I'm proud of not taking the time to think a problem through, but sometimes people act really weird when under the gun.
Trite though it is, admitting that you don't know truly is on the path to wisdom.
Not taking time to think things through is endemic in the workplace, not just an interview quirk.
in the real world, many O(N) algorithms are in fact O(I don't know) because of unexpected or unpredicted behavior from language, compiler, interpreter, runtime, os, etc.
O(N^2) means that your operation gets n times slower each time n increases.
2000^2 is 4 million. (n log n = 6600)
200,000^2 is 40 billion. (n log n = 1 million)
My point is for a lot of cases it doesn't matter, and just because someone can't throw off the top of their head the O complexity of some algorithm they just wrote in a stressful interview does not mean they don't understand the concepts.
Besides a O(N log N) algorithm over 10 or 100 items is not going to cause any issues. In the case of your standard CRUD application that's what you are going to be dealing with.
> Besides a O(N log N) algorithm over 10 or 100 items is not going to cause any issues. In the case of your standard CRUD application that's what you are going to be dealing with.
I think you mean n^2. n log n is generally considered pretty decent.
But you're wrong, I know from experience that simple CRUD apps can suffer from grindingly poor performance, caused by, let's say, optimistic assertions of data volumes.
I am yet to have seen a basic CRUD app that had performance issues due to a bad coding algorithm. Certainly from poor queries but never from an bad algorithm.
Keep in mind I would say that a simple CRUD app with millions of entries is no longer a simple CRUD app.
select * from table;
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.
I didn't mention not being able to reason out the complexity, only saying its O(N^2) off the top of your head when presented with some method.
To be sure, not being able to reason outside of the canon is a long-standing occupational hazard and trait of the humanities, so there could be something a little more pathological in perpetuating these interviewing techniques.
Not nearly as relevant for someone using scripting languages and building UIs.
I've used slow web pages that show a lot of items or data. One way to make them slow is O(n^2) DOM manipulation (e.g., inside a loop over items in a page, O(n)-searching the page for something).
Knowing complexity theory isn't the only way to find performance problems, and sometimes isn't even relevant, but it sure is helpful.
Sometimes you have to make a decision to just go with the inefficient solution, but I'd like it to be an informed decision if the codebase is one I have to work with and maintain in production.
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.
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.
I don't know what your code's like, but I'm going to take a guess that it's above average. In my experience, people who think about the stuff you mentioned tend to write above-average code.
Let me tell you what I always looked for in technical interviews. I wasn't trying to determine whether a candidate was an utter genius who would offer novel and clever solutions to hard problems. That's too high a bar; most companies can't expect to consistently attract those types of candidates.
Instead, I wanted to see if candidates would write maintainable code. In other words, my #1 concern was whether the candidate was going to create a big mess for the rest of us to clean up. Will they pollute my functions with a bunch of special-case if statements because they had to add a new feature that doesn't fit into the current architecture? Or will they recognize the situation for what it is and start a conversation about changing the architecture? Will they take a class named Car and use it to represent a House, just because it exposes the method .door? Or will they recognize the importance of logical naming, create a new House class, and break out the .door method into a mixin? Stuff like that.
Not every interviewer makes that the #1 concern. We all have our pet peeves. But my point is, there's usually some very mundane, practical thing they're looking for. Not super-ninja-rockstar coder status. If you can determine what that practical concern is, you can then try to convince the interviewer why you're exactly what they need.
I'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.
> And for all of this I still blunder my way through an exercise to write a function which returns a boolean in response to the question of whether sequence A is a sub-sequence of sequence B. I still draw a blank when asked what the magnitude of complexity is for the guests function I just wrote (damnit, of course calculating the permutations of a list is n-squared, but this is an interrogation of the random trivia I can manage to recall and I feel like a deer in the headlights).
That does, to me, sound like you do, in fact, have a problem with interviewing. The article is light on concrete facts to build off of, but if you're the kind of person who represent yourself to me (interviewing you) as having such an impressive toolbox as you certainly do seem to have in your possession, and then go on to fail to write a simple function and answer one of the most basic analytical (and, opposed to many other stupid gotchas/shibboleths, actually important) questions in computer science, then my "talker, not doer" red flag goes up, and you're going to have an uphill battle from there.
Basically, it's a case of over-promise and under-deliver.
Again, there is precious little concreteness to build off of, so this is very speculative: try to "modesty-fy" your CV and make sure you don't come off as bragging in any way in the beginning of the interview: under-promise. Also, do some whiteboard code katas. Then do the simple task, ask for help if you black out, and then put in the punch-line: "Actually, there's a really neat way to do this in Lisp".
I really have to work on this.
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.
You mention that there isn't a better solution. IMHO, I disagree.
I think Github has figured out a way. They've been around 5 years and haven't fired anybody and nobody has quit.
Most firings are due to a job / job skill mismatch. At Github, they do a week long paid interview so both sides really know what they're getting into.
I don't work at Github, but am such a fan of their company.
Lesser companies simply have to take more chances on people if they want to have a shot at growing their teams. They will naturally fail more than companies that don't have to take that shot.
Also, GitHub just have 166 employees (https://github.com/about) - presumably not all engineers. Any ten random selected medium sized software companies easily eclipses their volume.
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
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.)
Certainly the hiring practices of Google et al, generally the worst perpetrators of cs bingo in my experience. Started a startup, you say? Rebuilt a non-trivial webapp? Won a hackathon? That's great, but we're going to need you to implement red-black trees and variations of fizzbuzz until your brain bleeds.
But I didn't give a crap, because hiring is something you're kind of coerced into doing (it's not technically required, but not doing interviews looks bad at promotion time). And I hated doing interviews with a passion, so I'd just give them one impossibly hard question, which is easier than asking a bunch of questions.
Would you be willing to share any of the questions you asked? Your description here has piqued my curiosity.
Sometimes I have to stop myself doing this before conducting interviews. I think it's an ego thing, or perhaps an insecurity. When I worked at Amazon the culture drove this kind of rubbish and skewed our hiring process immensely.
There was something perverse about being in an interview loop, all 8 of us "not inclined" to hire a single candidate because they missed an recursion terminator in a solution to something properly complex and scratched out on a whiteboard in 15 minutes. All of us nodding like "that's so stupid" and I was sitting there 100% certain of the 8 people in the room the 7 of us who hadn't conducted the same interview 50 times would drop a bollock somewhere along the way. Yet there was no way this "otherwise competent, and quite nice guy" was as technically astute as all of us gathered here today indulging in our nice cup of ego massage while other people got actual work done.
Now when I interview candidates I want to see some code you have written you are proud of. Above all, I'm looking for pragmatism, effective reasoning and discipline in execution.
I love the idea of a paid working trial of some length, followed by a permanent hire but I've yet to convince the powers that be that it's an effective strategy.
I prefer to hire a candidate that might take 2-3 months to get productive but have some really innovative ideas, that others in the company might have missed. Puzzle questions do give me a sense of how someone approaches and solves problems, and I think you can infer how they will handle real problems since the building blocks to problem solving are essentially the same regardless of what domain. Solving puzzle questions is just a component of things I look for:
1. Experience in solving challenging problems 2. Good university results 3. Personality fit, easy to get along with 4. Leadership potential 5. Enthusiastic/passionate
Not all five are needed, but candidates need to be strong in more than 1-2 areas.
If you have issues with interviews specifically, you could enter a TopCoder competition, or Google Code Jam, and use that as evidence that you can solve those types of problems.
As a passive job seeker, I think this is something I've used to filter out companies. Ones that want to hire someone yesterday are more likely to suffer from poor planning and may only care about short term results.
I'd rather have someone who may take 2-3 months to get up to speed, and then spend years with me returning that investment more than a simple mercenary that will be with me a year or two and then move on.
How long of a trial are you thinking of? If it's a significant amount of time, I think this could be hard to do from the perspective of the candidate.
If I'm currently employed, there's probably no way I'm going to quit my job for a month-long paid trial period somewhere else. If it didn't work out, I'd find myself without a job and would be forced to take a hopefully short sabbatical for more interviews (and this wouldn't be possible at all for people who haven't saved up enough money to do so). It just seems too risky.
If it were longer, say six months, I might consider it, but I'd expect a decision to be made well before the end of the sixth month--that way if you didn't want to hire me full-time I'd have time to talk to other companies before losing my income. Even with this concession, I'd have to want to work for your company an abnormal amount to do this, though.
Perhaps a happy medium is a take-home project taking one or two weeks of part-time work, paid for at market wage.
However, I do meaningfully disagree about "variations of Fizzbuzz". It does make sense to vary fizzbuzz, if you suspect that your candidate will have literally memorized the solution, character for character. If that's a concern, though, trivial variations are sufficient: replace the 5 with a 7, or change the ELSE case from "print the number" to "print nothing", or something.
I agree that if your "variation" makes it "interesting", you're not doing Fizzbuzz.
Whether or not interesting programming puzzles are a good element of interviewing, well, there continues to be a wide range of opinions on that.
What I was responding to was "variations of fizzbuzz until your brain bleeds". Which I interpret to mean doing a fizzbuzz, then the interviewer changes it a bit, and a bit more, and keeps dragging it out, having misinterpreted its purpose. Certainly the one and only "fizzbuzz" test you give a candidate can vary from individual to individual.
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 think that the problems with technical interviews is that they focus more on algorithms than actual code. While this practice is good for recruiting students out of school who should know by heart the most efficient search or sorting algorithms, it puts people who have been in the industry or who often work in freelance jobs at a considerable disadvantage.
Unless you are working at Google or Facebook where efficiency is super important, the interview questions that Silicon Valley companies ask often do a bad job of filtering out the right candidate.
I thought that your hack was very good. I think that you could turn it into a business if you wanted to.
I was told that the only reason I didn't win the grand prize was some of the judges didn't think I could have made the app by myself during the competition/I had cheated.
Honestly, I'm more flattered that they thought I was too good to win than I would have been if I had won. :)
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.
You might want to take a lot more time working on that personality if yours. Everything you wrote in your post and your post's general tone screamed to me "humorless with a chip on his shoulder."
And dump the self deprecation bit. No one's gonna hold your hand here. I doubt you're a bad programmer, I just think you suck at being likable. Shitty, I know. Now do something about it. Much more than you've been doing. Be approachable. Politics will always get your much further than skill.
I don't know the guy, so I'm not qualified to comment on his personality. From the several paragraphs I have to decipher his personality, he doesn't seem like a bad guy, and he seems to be good at communicating his thoughts. Maybe he's just looking for jobs in all the wrong places?
I think you really hit on something here.
I think the concept of "scared money" applies here. He's interviewing from a position of weakness (not having a job in hand to fall back on) and that causes him to perform in a way that could be coming of as desperate and dejected to interviewers. Some people are better at hiding that than others, but i'm thinking the author might have an issue with it.
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.
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.
How about a link to the contributions? Perhaps you can get some better feedback from people looking at those. Why the blundering? It's not a memorization exercise, it's an exercise in counting and math: 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.
It won't fix your short term financial problems, but it might be your long term salvation.
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.
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.