141–150 of 163 posts
We often find that there are plenty of technically qualified people out there, but what you can do isn’t the only factor in hiring. The most important thing about hiring talent is finding talent that works well with your existing talent. In other words: finding a good CULTURE fit. There are LOTS of smart people out there, but only a small percentage of those people are sociable enough to really do an exceptional job…
There are simply very few positions for programmers throughout the country. That includes the Bay Area. As much as everyone wants to believe it isn't true, it's true. There's very little demand and way too much supply. Programming is a losing profession, and if you're in it you should get out while you still can. Get into sales, marketing, and/or management instead.
Then apparently we're the only company that has crazy number of openings and I personally talk to people every week that aren't what we're looking for.
As a developer looking for work, I am curious what you are looking for in your future employees. Looking at your profile and comment history gives me no hints.
Perhaps you have enough people to weed through that you don't want to post here and get a few more, but I know that I am not the only developer on HN that is looking for work. I'm also certain that other people would also appreciate knowing where to look for employers who have "crazy number of openings".
Thanks,
Earlier quoted context omitted.
Why not give everyone a simple test, but give A LOT of people a simple test (which SELECT statement is an inner join...)? What I always here is that 90% can't write a for-loop or a basic regular expression, but look great on paper, and vice versa. EDIT: Recruiters are probably too stupid (usually) to be able to either administer or evaluate such tests and so will always be more interested in the "crisper" resume whic…
> give A LOT of people a simple test (which SELECT statement is an inner join...)? That is like asking, how do you implement a reduce function in CouchDB? The answer is easy, and would only take a couple of minutes with Google to answer, but I bet even many top programmers could not answer that question off the top of their head. If you are looking for someone who writes SQL queries all day long, maybe that is a good…
Another thing is that some candidates (or their recruiters?) "inflate" their resumes claiming expert knowledge for things that they heard about in passing or maybe did some trivial task with it. Asking such trivia knowledge allows to find it out very quickly - if one claims to be SQL expert with 5 years of experience and don't know what inner join is - he's probably lying. And this is a bad sign - to start relationship with a lie. I know some people like to do that (especially because of the keyword-match approach) but it's a huge turnoff to start an interview with a supposed expert in the field you need and find out the most work he did in the field was a toy project 10 years ago in college of which he remembers nothing and isn't even interested in doing that.
There are simply very few positions for programmers throughout the country. That includes the Bay Area. As much as everyone wants to believe it isn't true, it's true. There's very little demand and way too much supply. Programming is a losing profession, and if you're in it you should get out while you still can. Get into sales, marketing, and/or management instead.
>That includes the Bay Area. As much as everyone wants to believe it isn't true, it's true. Source? Extraordinary claims require extraordinary evidence (or at least some.) There is plenty of evidence that counters your claim. (To start with, craigslist.org/sof has 90 listings on Friday while in 2004 I remember when it had like 8.)
> Companies shouldn’t be turning qualified candidates.
> I feel like there are so many reasons to hire me
> I didn’t get to talk about the iPhone app I built.
Stop right there. You are not generalizing. You are talking out of your ass. I am always shocked when I run across people my age who are so arrogant. No matter how qualified you think you are, there will always be problems tougher than you have faced, hw architectures more delicate and complex than you have dealt with, and people who can blow your mind in ways that you cannot imagine. When you eventually acknowledge this, you should be grateful for the opportunity to learn what you can every day and that someone is paying you to do it. Fast forward 10 or 20 years and then we can start talking about value.
Earlier quoted context omitted.
> give A LOT of people a simple test (which SELECT statement is an inner join...)? That is like asking, how do you implement a reduce function in CouchDB? The answer is easy, and would only take a couple of minutes with Google to answer, but I bet even many top programmers could not answer that question off the top of their head. If you are looking for someone who writes SQL queries all day long, maybe that is a good…
I would disagree. There are questions which if you fail to answer this means your understanding of the field is near zero. For SQL, I would say question about "which kind of joins there are and why" is like this - if you don't understand this, you don't understand relational databases. Which may be OK if the job does not require that, but at least you'll know that about the candidate. Another thing is that some candi…
This is like saying if you can't write a controller in Ruby on Rails off the top of your head, you do not understand programming. SQL is a vendor-specific technology, and while it is related to relational databases, is not tied to the underlying theory. You can have a relational database that does not use SQL at all.
> if one claims to be SQL expert with 5 years of experience and don't know what inner join is - he's probably lying.
I agree with this. If you want to hire someone who understands the inner nuances of, say, MySQL then it may be a good question. This is quite a bit different to understanding relational databases though – one is theory, one is application.
There are simply very few positions for programmers throughout the country. That includes the Bay Area. As much as everyone wants to believe it isn't true, it's true. There's very little demand and way too much supply. Programming is a losing profession, and if you're in it you should get out while you still can. Get into sales, marketing, and/or management instead.
Then apparently we're the only company that has crazy number of openings and I personally talk to people every week that aren't what we're looking for.
Earlier quoted context omitted.
Silicon Valley is almost entirely white That's far from the case.
In small startups it's white, Indian and Asian. There are occasional women but less frequently as programmers. Women are more common as designers and sometimes sysadmins, though. Bigger companies don't look like this. They look more like big companies all over.
Earlier quoted context omitted.
I would disagree. There are questions which if you fail to answer this means your understanding of the field is near zero. For SQL, I would say question about "which kind of joins there are and why" is like this - if you don't understand this, you don't understand relational databases. Which may be OK if the job does not require that, but at least you'll know that about the candidate. Another thing is that some candi…
> For SQL, I would say question about "which kind of joins there are and why" is like this - if you don't understand this, you don't understand relational databases. This is like saying if you can't write a controller in Ruby on Rails off the top of your head, you do not understand programming. SQL is a vendor-specific technology, and while it is related to relational databases, is not tied to the underlying theory.…
Yes, you can have relational database that doesn't use SQL at all - how many of those are around and popular though? There are some, but not many. What are the chances that you worked with a lot RDBMS, yet never encountered SQL even at the basic level, and it is not immediately evident from your resume, which still says "SQL"? But OK, if that's the situation, you can say "you know, I worked with non-SQL relational databases, and let me tell you about this cool thing I've done that is way better than SQL JOIN can do" - and that might be fine too. Usually though the case is just that people inflate their resumes and think they won't be called out on it. It's very unpleasant because when you interview somebody whose resume looks good, you unconsciously plan that you'd get a great addition to your team - and then you discover he doesn't even know joins... Bummer.
BTW, inner join has nothing to do with MySQL inner nuances - it exists in virtually any SQL implementation out there AFAIK.
Earlier quoted context omitted.
George, I really like your laundry-list post - and you're right, it could be much longer (at the very least, break "web programming" down into frameworks). And it inspires a thought that is only tangentially related to the OP's point, and that is the utility of fragmentation. There's a curious phenomena that when you list all of the languages out like that they all seem so...equivalent. And yet they are only equivale…
I have encountered a few (too few) companies who recognize the equivalence of languages, and recognize that moving from, say, Python to Java isn't very difficult and isn't nearly the same gulf as trying to move from C to Java. That said, the proliferation of language/framework-of-the-week projects is a serious drag on the industry. Its too easy right now to roll your own framework/JVM language/interpreter. The tempta…
Presumably if we could show this then the world's programmers could focus on porting old code into "Codesperanto" and everyone would be happy(er).