The people who matter aren't going to comment on this, but I'm out celebrating, so what the hell. I was actively looking for a job until about 6 hours ago. I read lambda calculus papers for fun. Hayzap, and the class of companies hayzap belongs to, is not even on our radar. Hayzap does not have hard problems and does not need a team who can ace this interview, and those of us who can ace this interview are uniterested in you. We don't want to take your worthless equity and we don't want to take a 50% pay cut for the privilege of working for your startup.
I think I understand what you are saying, but I don't understand how it relates to the article. For example, the article doesn't seem to say anything about Hayzap being boring and a turnoff to engineers on account of paying 50% of market and offering worthless equity.
It sounds like there is some personal history here. Is there?
(parent again) even though my comment seems popular by votes if not comments, i wish i had checked my tone more carefully, i blasted it off from my phone from a restaurant. i'm just reflecting that there's just an awful lot of startups--perhaps with an interesting business challenge but straightforward technically--who talk about how they only hire A players and how difficult it is to hire, when really they need a competent ios or rails guy, and the contracting market is swimming with them, and they're making a ton more money contracting than the type of startups i'm familiar with wants to pay. the devs who know lisp and haskell aren't building apps, they're architecting enterprise integration contracts or building databases.
*i don't have a relationship with hayzap and i've never worked for a CMS company.
I find it rather sad to see such bitterness and cynicism. Somebody took the time to write a blog post in order to help people, and the reaction above was one of anger.
I stopped reading at exactly this line. With it he established that he's merely speculating, and quite frankly I'd rather live with my own speculations than his.
Nothing new here. These are just someone's notes on hiring (the post does not at all deliver on the title). It's all been said before, and in better ways.
Also I'm tired of the "learn C" mantra. You don't need to know this language to understand pointers and their difference from references. Or the different approaches to memory management.
Learning C is a pretty simple way to learn about pointers, low-level memory management, and so on. It's not the only way, but it's one of the better ways. You also learn a fairly popular programming language as part of the package; not a bad deal!
I've yet to interview anyone that didn't know C or C++ but correctly understood pointers and references. Of course that's not necessarily bad since it's not a useful distinction in some higher level languages.
One of my favorite interview questions is do binary search when the function prototype is this:
int bsearch(int *values, size_t len, int term);
By the time we finish going through this exercise. I have a pretty good idea how they do with basic algorithms and indirection (pointers). In fact, pointers are a great way of testing a candidates ability to deal with indirection.
You can come up with simpler C pointer questions that also do not require tricks but this does the trick for me.
And yes, everybody gets binary search wrong, but that's okay. I learn a lot about a candidate when they are doing the exercise.
Bland, generic, and inaccurate advice on what to learn/practice before interviewing.
The comments here have corrected several problems with your understanding of functional languages, which leads one to believe that you have dabbled with them, but really don't know them all that well.
You are attempting to target a more experienced demographic of developer, but your article is catering to newbies. Masquerading as a guide to 'Ace a Startup Engineering Interview' is just salt in the wound.
We don't need any more guides on preparing for interviews. There are several good ones that exist, the advice that already abounds isn't going to expire anytime soon.
It always amazes me how people keep recommending CLRS as an interview preparation material. If you haven't studied Algorithms before it will take months to go through material in this book, leave alone making exercises. It is a serious textbook with strong mathematical rigor. If you have studied algos, granted, you would know what book to pick as a refresher and chances are - CLRS would be on your table.
I think Sedgewick's book would be a more practical choice as a first book to learn some data structures/algorithms.
I think these are applicable to any engineering interview. The key to every tech interview is most of the time is less about your actual answer but how you get there. If you code something that clearly would never work in any language, you won't get the job. If you code something decent, have a great thought process and in general communicated what you were thinking about the problem, you will most likely get the job. Remember the more you can demonstrate about yourself during the interview the better. The interviewer has a couple of hours to make a decision that can affect their bottom line pretty heavily. The more information you have (Github, Resume, references) the easier it is for them to feel comfortable with you and the easier it is for them to give you the yes.
i dunno... you can get pretty far as a Data Scientist with two stock answers: (i) look it up in a hash table or (ii) look it up in the literature... I think I'll ask the next guy how to train a neural net to make that decision. ;-)
but at what point does that alone make them a scientist?
(NB: I actually froth at the mouth over the weakening of the word scientist, when the way in which many folks do "data science" is not in accordance with any scientific principles.)
Well said, why not learn one framework and high level language and launch your own startup. In the beginning Facebook needed only php, twitter needed only ruby before moving to Java. Instagram is 98% python. When you begin to gather traction, you will employ the alpha geeks who use C, some of them are in Facebook and Twitter today. So just focus on building a product that succeeds with one or the only single backend language that you know in addition to some javascript and then use twitter bootstrap for design.
Why burn all that learning time to get a startup job, probably with reduced salaries and equity that might amount to zero if it fails. This is thesame risk you will face with your own startup but the difference is that the upside or equity is bigger if your startup takes off and you are doing it with the one language you know.
One key skill that is needed in a startup is how quickly can you learn and adapt.
We try to figure out how quickly a person can learn and be productive by giving a small problem in an area that the candidate is not strong at. We then give them the complete internet access and a development environment and ask them to write code for the problem. We also pick a problem that is highly relevant to the day to day work, not a theoretical one.
I really appreciate this post. As a job seeker, I like reading this kind of tips. What is more, it has told me that all the things that I'm doing just for fun and for the passion that learning new things give, is being useful also for this purpose. Indeed, I think that the opposite direction is the weird one, since I can't see the point of learning C, algorithms,... just for the job seeking intention. You really need to enjoy that stuff.
[+] [-] dustingetz|13 years ago|reply
[+] [-] slurgfest|13 years ago|reply
It sounds like there is some personal history here. Is there?
[+] [-] dustingetz|13 years ago|reply
*i don't have a relationship with hayzap and i've never worked for a CMS company.
[+] [-] danielrhodes|13 years ago|reply
[+] [-] anika11|13 years ago|reply
I am sure the engineering challenges at a very small, simple CMS site are truly mind boggling.
[+] [-] DanWaterworth|13 years ago|reply
Wha???? You didn't even mention Haskell under pure functional languages, but listed three that aren't.
[+] [-] tsm|13 years ago|reply
[+] [-] immad|13 years ago|reply
[+] [-] heretohelp|13 years ago|reply
[+] [-] pepve|13 years ago|reply
Also I'm tired of the "learn C" mantra. You don't need to know this language to understand pointers and their difference from references. Or the different approaches to memory management.
[+] [-] pjscott|13 years ago|reply
[+] [-] zeroonetwothree|13 years ago|reply
[+] [-] bcbrown|13 years ago|reply
[+] [-] thisisnotmyname|13 years ago|reply
"Improve your Theoretical knowledge" ...followed by... "Learn C"
I obviously have a completely different idea in mind when it comes to computer science theory than the author does.
[+] [-] mtanski|13 years ago|reply
int bsearch(int *values, size_t len, int term);
By the time we finish going through this exercise. I have a pretty good idea how they do with basic algorithms and indirection (pointers). In fact, pointers are a great way of testing a candidates ability to deal with indirection.
You can come up with simpler C pointer questions that also do not require tricks but this does the trick for me.
And yes, everybody gets binary search wrong, but that's okay. I learn a lot about a candidate when they are doing the exercise.
[+] [-] baddox|13 years ago|reply
[+] [-] shock3naw|13 years ago|reply
The comments here have corrected several problems with your understanding of functional languages, which leads one to believe that you have dabbled with them, but really don't know them all that well.
You are attempting to target a more experienced demographic of developer, but your article is catering to newbies. Masquerading as a guide to 'Ace a Startup Engineering Interview' is just salt in the wound.
We don't need any more guides on preparing for interviews. There are several good ones that exist, the advice that already abounds isn't going to expire anytime soon.
[+] [-] dmitrykoval|13 years ago|reply
[+] [-] kirinan|13 years ago|reply
[+] [-] immad|13 years ago|reply
[+] [-] PaulHoule|13 years ago|reply
[+] [-] carterschonwald|13 years ago|reply
[+] [-] immad|13 years ago|reply
[+] [-] criveros|13 years ago|reply
[+] [-] throwa|13 years ago|reply
Why burn all that learning time to get a startup job, probably with reduced salaries and equity that might amount to zero if it fails. This is thesame risk you will face with your own startup but the difference is that the upside or equity is bigger if your startup takes off and you are doing it with the one language you know.
[+] [-] throwa|13 years ago|reply
Check out the hackernews discussion on the subject: http://news.ycombinator.com/item?id=4275140
[+] [-] ad93611|13 years ago|reply
We try to figure out how quickly a person can learn and be productive by giving a small problem in an area that the candidate is not strong at. We then give them the complete internet access and a development environment and ask them to write code for the problem. We also pick a problem that is highly relevant to the day to day work, not a theoretical one.
[+] [-] ichinaski|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] scient|13 years ago|reply
[deleted]
[+] [-] pjscott|13 years ago|reply
[+] [-] icn|13 years ago|reply
[deleted]
[+] [-] liveink|13 years ago|reply