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.
EI is when you take existing large systems and you make them work together, and its really hard because the systems aren't designed to work together, and made harder because bigco internal teams aren't exactly known for the quality of their infrastructure.
Relevance is one famous company that staffs world-class engineers and does EI[0]. They also write databases[1]. and languages[2].
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 think the blogpost is worse than helpful, as the author is simply parroting common hiring tropes, then adding misleading advice. Consider:
* He recommends CLRS for learning the basics of algorithms. This is like reading baby Rudin to learn about the basics of numbers.
* He edited his post 2-3 times because he can't identify whether Common Lisp is a purely functional language or not.
* He mentions that side projects don't need to be complex, then suggests "simple" iPhone apps or open source libraries. In practice, neither of these is "simple."
Please refrain from such personal attacks. I don't understand what prompted the OP's comment (but in my experience it's largely true). That said, there's another axis of motivating job: those with social impact. wingspan.org offers a "24-hour anti-violence bilingual crisis line". It clearly appears to be a socially rewarding job.
And you left out his earlier job, at a company which is known for significant "engineering challenges".
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.
Scheme is a bit more biased in favor of functional techniques though. Recursion (in the vast majority of cases CLers will just use (loop) instead of recursing), continuations...
I'm a heavy Common Lisp user, but I'm only casually familiar with Scheme, so I opted to leave deconstruction of that aspect to others--such as yourself!
He's making the distinction between saying a language is "functional" versus "pure functional." It is not correct to classify Lisp and Erlang as pure functional languages, because they both include support for imperative style programming.
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.
I sorta know both, but I'm generally more comfortable speaking in terms of Lisp than C and if an interviewer forces me to speak in terms of C I'm likely to be less cogent.
Working with pointers in C or C++ is a decidedly lower level construct that Lisp. Not to make any sort of value judgement between the two languages - but with a c pointer, you are accessing a very specific point in memory. If you're pointing to the first element of an array, add one to that pointer, you're now accessing the second element of that array.
This close to the metal mindset is what makes C/C++ valuable for learning how code compiles to assembly, and understanding _how_ your program is executed.
That's an implementation detail that doesn't bear much on actually using the language. The cons cell abstraction leaks sometimes, sure, but I wouldn't say that the concept of "pointer" is fundamental to Lisp at all.
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.)
Same thing for engineers IMHO. Where I come from the title is regulated, so it requires a bachelor's degree with a specific list of courses and 2-3 years of work experience as a junior engineer in the specific field to call oneself "engineer". But in the country where I work, there are plenty of people with no programming experience who can setup a wordpress site or grab a Microsoft certification and instantly become "system engineers"...
Thats why my card says "Computer Scientist". :-)
People ask what that means a shockingly often fraction of the time!
They ask "so what do you?", I say "computer science", they then ask "what parts?", I reply "all of it". Thats of course ignoring the conversations where they then ask what computer science is or how thats different from programming or setting up a web server. those chats are tough :)
In general, it is highly inappropriate to title yourself a scientist without a PhD. A 20 year old undergraduate with an enthusiasm is not a biologist. You claim to hate the dilution of the title, yet have upgraded yourself without earning it by either mastery produced via a doctorate or via a proven professional track record.
Maybe you should consider titling yourself software engineer or program developer until you've produced something that shows mastery to the world.
you're making claims based upon social convention, but I do not see any evidence that you have authority with respect to making such claims.
The issue with the phrase "data scientist" is that it is overused, is highly ambiguous in what people mean when they say it, and when someone identifies themselves as such does not communicate any clear lower bounds on expectations of relevant background and skill.
This is not an appropriate fora for getting into an argument about what formal training vs autodidactism (i have plenty of both) is sufficient for being a scientist of one sort or another.
I am open to hearing reasoning that isn't based upon institutional validation. There are many scientists whose work is not in the domains which they had formal training, eg Oded Schramm, Cosmo Shalizi. They could be considered amazing scientists, but surely they were scientists by intellectual inclination even before they did their great work, and likewise successfully defending their phd's didn't make them scientists, it merely gave them the title of doctor!
Calling oneself an engineer of software is misleading in my mind, because in many countries engineer is legal certification of reliability.
Calling myself a program developer would be a gross misrepresentation of what I do, so i do not call myself that. I solve hard problems and build better tools for solving hard problems.
As for showing mastery to the world, I care not, open source is great, but ability to self publicize, or have great open source projects, have absolutely no relationship with being a good computer scientist, though they work synergistically together in a wonderfully positive way.
At the end of the day, everything is some sort of social convention, and the folks who I respect would consider me a computer scientist, and thats good enough for me.
have a great rest of your day on the internet good sir.
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.
Ever since C++ got switched out by the major universities (in the US) for Java (circa 2001), there have been fewer and fewer people who learn/know C/C++ and who can then also understand pointers and other C related knowledge. It's not completely unused but for the most part it has been relegated to game programming and systems based work where speed is important.
I am sure there are exceptions or other reasons to this, but I feel that once the universities switched over to Java, C/C++ went on a big decline.
I love the freedom I have with C/C++ and although it's true I used a lot more Java than C at university, when speed is of relevance I usually go with C/C++ (usually a weird mix of both). And if it's not, my first choice is Python.
Though it's generally true that most of my friends prefer Java over C/C++. I might be different because I learned programming in high school and started with C.
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.
