In my experience, technical questions aren't usually language-specific per se. Instead, they focus on algorithms & data structures. Are you getting a degree in Computer Science? If so, you should be pretty well-prepared for technical interview questions already.
AI and Machine Learning are very interesting fields, but you need a deeper understanding of CS than you do for mobile/web development. Just out of curiosity, are you familiar with what a state-space search is, and the difference between breadth-first and depth-first?
edit: FYI, I'm also C.S. major graduating this semester. I consider my interests to lie in AI and ML as well. I've not had any trouble with technical interview questions.
Author is applying to wrong companies if he is getting lots of language-specific questions. The right kind of company for him is probably one that is looking for smart people who can program and not for Java jockeys.
It's a nice story, but for every Sex Pistols there are a bajillion other talentless bands who executed their vision with ferocity and never went anywhere.
This is assuming one accepts your definition of talent. Is it true that they had no talent? If they couldn't play their instruments, sing, or write lyrics, why did anyone listen to them? There had to be something there. If anything I might say it requires substantially more talent to overcome an utter lack of skill in order to excel.
Also, all else being equal, additional skill or talent won't hurt.
Bottom line: the stories you hear about people who go from nothing to incredible success are outliers. I think determination is absolutely underestimated relative to raw talent, but that determination should be leveraged in service of developing skill and/or harnessing talent, not in lieu of skill or talent.
...as long as somebody else is telling you what to do.
The Sex Pistols were really the creation of their manager Malcolm McClaren. Which really is kind of apt, because if you don't cultivate your talents, your successes all depend on someone or something else.
I work at a newspaper and since I've been here (8 years now, I'm 28) I have learned some skills:
* Advertising Design(Print and Online Ads)
* Layout Design
* HTML
* CSS
* Some JS
* PHP
* mysql
* Currently teaching myself Python
* Online Advertising (Booking Campaigns)
I know how to do a lot, I just don't feel like I'm good at any of it. This is where I feel Jack of all trades (master of none) is an insult rather than a compliment.
Like the author I feel that if I apply somewhere else my skill level might not be up to par. It really is frustrating.
I second that emotion. It can happen very easily (well, it did to me) if you're feeling "down" or particularly unsure about the future.
And yet, why would we need to be "Master" of anything?
One thing struck me in Hery's post: He did things. He accomplished. And many of these things he seemed to enjoy doing. How many of us here, with our fancy degrees and self-taught knowledge have lots of projects "on the side", always thinking "I'll do it when I got time" but never actually DOING anything? Like kids in front of a box full of LEGO, rummaging through the pieces, putting two of them together then going through it again,... In this age full of distractions (let's look at your reddit karma again, and are you sure your inbox is empty? maybe someone tweeted something interesting in the last five minutes), the value of your knowledge ain't "jack", your value as a developer lies in what you can accomplish.
Don't mind the bullshit job offers asking your for "ten years in java, 20 years in ruby and 50 years in BASIC (knowledge of COBOL a plus)", most companies would KILL to have someone as devoted (and versatile) as you.
This is a failing in job interviews in my view - selecting for skills that might not matter in practice. If you can build decent working code by Googling stuff as you go along (I know that approach works for me at least, besides the poster), there must be some real value to that which interviewers are missing.
It (usually) isn't a binary decision as to whether or not a candidate adds value to the company, but rather a decision on whether or not the candidate adds more value than the other candidates interviewed for the job. Given the choice between someone who can code sans-Google and someone who needs to constantly copy-paste from Stack Overflow, I'll take the guy or girl who can code on their own.
Of course, this doesn't mean I think programmers shouldn't use Google or Stack Overflow, I use them all the time. However, the specifics of what you're Googling matter a lot. If asked to implement a Red-Black Tree and you have to Google that to get an idea of what it is (or to refresh your memory) that's one thing, but if you have to Google basic loops or "FizzBuzz level" basic discreet logic constructs to implement simple code, then that's a huge problem.
It depends on the nature of the problem, but you are actually very solid with language skills (you know at least 4 or 5 different languages with sufficient skill that you can develop subtantial apps with them and not trip over yourself in language minutiae) it might not be a bad idea to gently twist the truth, assuming you can pass the technical tests.
Lest anyone think this is unethical, do remember that the large majority of job postings are made by people who ask the impossible (a level of experience in new languages that basically make it accesible only the language developers) or the irrelevant. Use your own criteria to determine when this makes sense.
Work through the latest edition (4) of Sedgewick's Algorithms book and do the algorithmic challenges on Interview Street.
This will fix the problem of having a wide range of hacker skills and a portfolio of projects but not being able to make it through a Google inspired interview.
There's probably a Coursera or OCW course that might help but the key is you have to actually do the exercises.
2. Specialize in one thing and never touch anything else again.
There's a bit of a middle ground. Have one (or two, or three) things you specialize in and develop great depth, coupled with a tremendous breadth of general knowledge of related things.
You could strive to be a "generalizing specialist" as they say[1] or a person with "t-shaped skills"[2].
"T people" are very highly valued, in at least some contexts[3].
I agree. I heard Donald Knuth endorse in an interview the notion of Thomas Huxley that one should "try to learn something about everything and everything about something".
The good news, and perhaps also the bad news, but in your chosen context the good news, is that Javascript, Python, Ruby, and to a lesser extent, Objective-C, are all essentially the same language. You're probably not as split as you think, and if you are going to stick within that paradigm you at least have perspective relative to someone who only knows one of them. You are right that you should really learn one of them deeply, but it hardly matters which, and a great deal of the deep knowledge will transfer fairly well. (Again, Objective-C being the odd man out a bit, but still in the same broad family.)
It seems to me that there's a developing consensus even in the deployment ecosystems. Everybody's growing towards what I might call a file-system-virtual environment per application, so you don't get conflicts in the "core" OS, automatic dependency management, etc etc, and it seems like the libraries grow ever closer to each other. What is one year some bizarrely-awesome library in one particular language is two years later copied in all the others. (Which is a good thing.) That whole family of languages is all headed for the same basic local optima, which is the bulk of why I would claim they're all essentially the same language.
In my experience, I have found that I needed to take a step back and focus on a solid foundation of technical knowledge that is totally language independent. After that, you can go back in and layer in how different languages might help/hinder you in particular situations.
Much of my education was from a "get cool shit done" perspective, and I did. I had solid projects in an array (no pun intended) of languages but lacked some of the true, lower-level knowledge as a foundation.
Your mileage may vary, of course, but if I could start my CS education over again, that would be my advice to... myself..
To the contrary, I think this sort of broad experience is excellent to have at the beginning of your career.
I'll admit I'm a little confused, as my entry-level interviews never involved any questions about language or API trivia. If I had to write code, I could do it in any language I wanted and was comfortable with. And sometimes I wouldn't even have to write code, just discuss a problem and potential approaches. The solutions would never depend on library-specific knowledge.
> I'll admit I'm a little confused, as my entry-level interviews never involved any questions about language or API trivia. If I had to write code, I could do it in any language I wanted and was comfortable with. And sometimes I wouldn't even have to write code, just discuss a problem and potential approaches. The solutions would never depend on library-specific knowledge.
Then you were lucky. A lot of interviewers can't get that far.
College is not the time to worry about spreading yourself too thin. It may seem like you're all over the place, but this is all just a drop in the bucket compared to the professional work you will do in the future. Most jobs will give you an opportunity to hammer away at the same code base for an extended period of time, and this experience will be far more valuable than doing a bunch of one-off projects in the same language simply for the sake of mastering said language.
In short, I think you're doing it right and will end up better off than someone who focused on one language because that's what companies appeared to want.
I can't speak about programming specifically, but for more general system engineering/administration I think I fall in this category and it has yet to hurt me.
I've had an interview or two over the years in which I surely lost out due to my inability to rattle off some bit of trivia about one thing or another, but it's probably for the best.
1) If the job was really so narrow that such a specific, rote depth of knowledge mattered I'd probably find it terribly boring.
2) If the interviewer is willing to write me off based on canned questions without actually conversing with me - the place where I feel I shine. I probably don't want to work for/with him/her.
Yes, there are surely exceptions to this, it's not a hard and fast rule, but as I said above it has worked out fine for well over a decade now.
I started with Assembly Language moving on to C/C++ for hardware programming. Then came Actionscript and PHP followed by Java. Got a job, they told me to be a Javascript, HTML/CSS guy. The next one asked me to do Python, C/C++, Java all at once. Left job, released a game written in Lua. Went back to work for a startup in Java(Android) and Python. I did that for 6 years(college included).
When I started working on my own startup(bootstrapping alone), and was in the exact state of mind as the author. "Well, fuck. I am average at almost everything I know." 8 months later my language skills have still not changed much, but I have found out that I can architecture projects better than my peers. Almost magically I somehow pick the perfect module for my project. I suspect that ability has developed by tinkering with different frameworks and languages over time. I still wish I had the freedom to be an expert at one. But in life you don't always get what you want. At-least now I have the ability to handle the technology stack of my startup alone i.e Golang, AngularJS, Android and iOS. It's not ideal but works out.
I have been thinking this myself recently, and contrasting how difficult it is being a founder (which pretty much requires a jack of all trades skillset), versus being employable until you can support yourself long enough to risk not having a job for a while (god damn student loans).
Given that the poster says "my ultimate goal is to build a general artificial intelligence" I'm not sure that facility in any given programming language (or the lack thereof) is the poster's biggest problem.
Build an application in Clojure and in C/C++. IMO you should try a functional language (doesn't have to be clojure) and a lower level language. It could be a clojure webapp and a C++ opengl game... doesn't matter.
I wouldn't worry about specializing just yet, just keep doing what you're doing, just up your difficulty level. Already you've done more than 50% of the programmers in the market (most know one language, like Java or C#).
My experience with technical questions during interviews is that they did not need a deep understanding of any particular technology. Instead, they mostly rely on some knowledge of algorithms and data structures. Almost all of my coding questions came from the following classes I took at MIT:
Intro to Algorithms (6.006)
Design and Analysis of Algorithms (6.046)
Mathematics for Computer Science (6.042)
Take some version of those classes (maybe OCW, edX, or Coursera) and you will be good to go — at least for technical interviews. If you like reading then Introduction to Algorithms by Cormen, Leiserson, Rivest, and Stein is the book that these courses cover.
Listen to this guy. Most interviews (even technical ones) don't dive that deep at all. Lets be honest, its just like your college courses. They just touch the high-points on the surface of the subject.
Try this experiment: ask someone in school who just finished a hard-sounding class (that you haven't taken yet) to interview you based on knowing answers to things they learned in class. It should sound mostly greek to you. From your perspective, you don't stand a chance of knowing the answers. But, now you know that the delta between not knowing and knowing is one semester, or if you're brilliant, two nights of cramming.
My point is, there is very little delta in what is required to prepare for an interview and what is required to prepare for year-end exams in any given subject. You don't need a lifelong working knowledge of theory. You need enough immediate knowledge of algorithms to get you past the meat-grinder. Remember how you crammed in college? You can get by most of the time by cramming hard for the interview. Also, you get partial credit for thinking out loud about the answers you're considering giving, if you're anywhere within a mile of the correct answer, the interviewers will likely give you a passing grade on the question.
Once you're inside, most of those challenging questions, well, they'll likely never come up again. Just like the stuff you "learn" in college.
Source: In my previous life, I was part of a team of developers who interviewed people for technical positions. We were mean, ruthless interviewers. I've also been through the meat-grinder myself a few times.
2nd year college student here--it feels that the structure and organization of coursework at many schools (including mine) seem to encourage this kind of learning. Projects that may seem technically involved but end up being a race to Google are common. Our school year, like those of many other schools is built around the quarter system. Quarters are ten weeks. It's not uncommon to be doing completely different and unrelated from week-to-week, and my first CS undergrad lab course was a good example of this kind of structure. One week you're doing bash scripting, the next week python, then you learn some basic git, rudimentary multithreading in C, and so on for 10 weeks. You'd hammer out an assignment only to forget the details of what happened days, maybe hours later. By the time the final rolls around you wonder how anyone would survive this course without the Internet or if we weren't allowed to bring copies of our notes and past code for the exam. Each assignment is a mad dash to learn just what you need to finish.
Of course, even with such brief bursts of effort, you can "relearn" quickly by consulting various references and refreshing your memory, but it becomes difficult and scary to imagine what life would be like if we couldn't look up whatever we needed.
"scary to imagine what life would be like if we couldn't look up whatever we needed"
It'd be scary to work out math problems without pen and paper. It'd be scary to cross over the amazon without an airplane. Applies to every tool you use.
I'd like to think of Google as my secondary memory (HDD?). All I seem to have is RAM.
I've noticed that there are two kinds of "makers" who get stuff done.
The first kind learns and learns deep. They are spooky good at it. They'll latch on to something and then follow it all the way down to its roots, learning it in tremendous depth to the point that their skill in it seems almost supernatural. After all of this, they say to themselves "now what can I build with this?" (Or find a place where an employer tells them this).
The second kind decides what they want to build up front and then pursues wide and varied avenues of technology on the path to this destination. They often have fascinating slivers of depth in certain areas but lack that magical seeming deep domain knowledge. These are the people more likely to identify as "self taught" with all of the downsides that come with that. They make up for this with ridiculous determination and a kind of sixth sense for what is possible if you try hard enough. Everything they know, they learn on the path to the destination.
Both can accomplish amazing things. You'll never hire one of the second kind. The second just isn't going to be able to show you pointer arithmetic on your whiteboard in your pet language.
I can relate to the author. I had a hard time passing exams in university due to undiagnosed concentration issues. I knew I was smart, but failing standardized tests left me feeling like an imposter. Regardless of finishing projects and tasks in the 95th percentile.
I am multilingual, an autodidact and I love programming. I also have a gift (your 6th sense) for engineering in that I am able to visualize and analyze machines/systems by glancing over the designs or watching them work. Combined with soft skills and programming experience this has proven of great value in industrial settings where I am able to relate and connect the mechanical, software and other engineering departments.
A couple of years back I started working at a start-up doing robotics and machine vision. Due to lack of time and personal I had to teach myself everything from inverse kinematics, path planning to a solid knowledge of 2D and 3D machine vision. In less than a year I was developing and integrating 3D vision systems and steering industrial robots. Only after delivering that first project on my own did I allow myself to internalize my accomplishments.
I might not have a formal engineering degree, but being a jack of all trades has proven to be a high value asset. It's about finding an environment where your (broad) skills pay off.
Generalizations as the one above make it harder for people like me to start a career as I very much belong to the second group.
Also, I can show you pointer arithmetic in my pet language.
The point was that current interview processes have no mechanism for measuring the second sort of individual. They don't have a way to measure tenacity and the uncanny knack of discovering the best way to do something when starting from ignorance(1).
tl;dr: A Google-like company would not have hired (someone like) Woz.
(1) Its double-hard because there are no shortage of people with tenacity who have the knack for doing things in a terrible way over and over. They all think they're in the former category.
I actually think this is the solution. Nothing would be more impressive than a python project that started out as a "c++ witten in python" project that barely worked but then evolved into a well managed project full of best practices in a matter of weeks.
I'd hire that person to do nearly anything. Sadly, not many interview processes are hip to github yet.
I am also a jack-of-all-trades and master of none. It's not that you won't get hired. It's that you won't get a nice salary, as you will have 'junior'-level skills for any field you apply for.
There are some positions where this obviously does work in your favour, but in general, you can be a junior in a bunch of jobs rather than a senior in one.
There are good companies that will hire people like us. Just keep searching. Hint: they are not startups, but boring, regular (but stable!) companies in boring industries. But you can go crazy getting them up to date with awesome software because they appreciate someone who knows what they are doing.
Both can accomplish amazing things. You'll never hire one of the second kind. The second just isn't going to be able to show you pointer arithmetic on your whiteboard in your pet language.
Maybe you won't hire the 2nd kind (as you say). Doesn't mean someone else will see the value in such background. Though there is an implicit message in your post. That all college trained programmers are the same. Which is downright wrong, due to there being a lot of different types of programmers. There are people who I wouldn't let near a database, but can really write some awesome C++. Or those who are awesome at writing web crawlers, but suck at making effective CRUD apps. Or maybe that guy who is a genius at VB.NET, and carries the weight of a whole company on his back (maybe he taught himself). You wouldn't hire those? Then you wouldn't hire yourself.
Hmm. I didn't specifically mention college education, but you've got something at the end there.
I am a college trained programmer, but I do identify strongly as the second type. When I really think about it, I'm forced to admit that if I was in charge of a large company's HR policy, that policy would probably prevent hiring someone like me for all but the most junior of positions.
A smaller company might have a lot more freedom in this regard. "You'll never hire one of the second kind" might better have been said as "big companies never hire the second kind".
Doesn't it make you think? Given the ratio of bad programmers vs good ones, should we even bother with degrees? From my experience, there are more bad programmers with degrees than there are without them. Like this project I just took over. It involves fixing the whole stack of a company, because some guys who had Masters degrees and had worked in IBM and NASA (two guys) managed to build a system so bad, that SQL injection is the worst of my worries (they never sanitize or check the contents of the GET or POST array (PHP)). But I, who lack a degree, much less a master's, am going in to get them set up with nginx, Python/Django and Mongo. Plus write re-write some custom systems because the geniuses used global variables everywhere.
But any big company HR dept. would hire them in a heartbeat.
Disclosure: I don't have a college degree. But I don't want to work on your big company either. (:
Self-taught programmer here and wholeheartedly agree. I've seen a lot of bad code from developers with high-level degrees and supposedly aeons worth of experience over me and yet it is I who goes out my way to write decent code and fix the professionals mistakes, I'm not exactly the first choice for a lot of companies because I wouldn't look as good as Tommy G with a masters degree would on a proposal document tendering for a big project as opposed to I who hasn't got any sort of showy trophy degree for a company to parade around.
Too many companies place emphasis on degrees instead of capabilities. I might not have a degree but that's because I thrive and learn a lot easier when I'm teaching myself as opposed to absorbing and listening to someone else drone on about things that might not interest me. At least when you're self-taught you only learn the parts that matter to you and so, you're more likely to learn them correctly.
You say it like these things are mutually exclusive. I know of several people who fall into both categories.
For instance, one of my good friends is one of the smartest programmers I have ever met. I've been bothering him to come down to our hackerspace (shameless plug: http://heatsynclabs.org) for YEARS, and he recently started obliging.
I came in one day and saw him sitting at a workbench hovering over a microscope.
Me: "Hey, Trav, what are you doing?"
Him: "Sharpening knives."
---
Ah, yes, of course. Because most people who want to sharpen a knife head down to the lab with a bottle of aluminum oxide because they want to use the microscope.
In the month since then, he has become an encyclopedia of knives. Every material, every manufacturer, every sharpening technique. I was at his house the other day picking him up for a road trip to Colorado, and his workshop is filled with sharpening stones (and rods) and different knives. On the ~9hr drive to CO, we went back and forth, me soaking up seemingly everything I could about knives.
Next month he's going to present at our little Tedx style event at the lab. (Members present on a topic they're knowledgable about).
But this obsessive learning technique isn't limited to knives. Back when we were roomates, he decided that he wanted to build a stepper motor controller, and I don't mean "assemble the kit from adafruit". He wanted to build a controller for the type of ultra-high-performance DC stepper motors found in hobby airplanes and helicopters because he wanted to build a quadcopter, but didn't want to use somebody else's electronics design. I spent that summer learning, by proxy, about control theory, what is back EMF, what do "closed loop" and "open loop" mean? How do motor controllers work, and why?
--
Examples of my friend aside, I think that your #2 is enabled by the traits that make up your #1, or that they can at least feedback into each other. You get the super broad domain knowledge because you've gone really, really deep into a few subjects, and can intuit most of the rest of the domain because of it.
Using the analogy of spoken languages ( a stretch I know ), I'd say there is a big difference in knowing enough to get by when traveling vs being fluent.
When a company is hiring, would they rather hire someone who can get by or a fluent speaker?
I think there is certainly a breath and depth balance to be had and I think you are correct in seeking more depth. A deep understanding of one language will allow you to more quickly gain depth in other languages.
You are a perfect fit for advertising agencies with digital departments. They usually need a jack of all trades. One who can build simple html/css sites, write Javascript, iOS app development and even backend development for larger campaigns.
51 comments
[ 3.2 ms ] story [ 103 ms ] threadAI and Machine Learning are very interesting fields, but you need a deeper understanding of CS than you do for mobile/web development. Just out of curiosity, are you familiar with what a state-space search is, and the difference between breadth-first and depth-first?
edit: FYI, I'm also C.S. major graduating this semester. I consider my interests to lie in AI and ML as well. I've not had any trouble with technical interview questions.
Yes, the punk band. Those misbehaving misfits that couldn't play their musical instruments and yet went on to change music forever.
The Sex Pistols succeeded with barely a shred of skill or talent because they were on a mission and executed it with ferocity.
No talent is required to make a difference. Just piss and vinegar and a grand vision. The Sex Pistols prove it.
This is assuming one accepts your definition of talent. Is it true that they had no talent? If they couldn't play their instruments, sing, or write lyrics, why did anyone listen to them? There had to be something there. If anything I might say it requires substantially more talent to overcome an utter lack of skill in order to excel.
Also, all else being equal, additional skill or talent won't hurt.
Bottom line: the stories you hear about people who go from nothing to incredible success are outliers. I think determination is absolutely underestimated relative to raw talent, but that determination should be leveraged in service of developing skill and/or harnessing talent, not in lieu of skill or talent.
The Sex Pistols were really the creation of their manager Malcolm McClaren. Which really is kind of apt, because if you don't cultivate your talents, your successes all depend on someone or something else.
Piss and vinegar definitely helps though.
I work at a newspaper and since I've been here (8 years now, I'm 28) I have learned some skills:
* Advertising Design(Print and Online Ads) * Layout Design * HTML * CSS * Some JS * PHP * mysql * Currently teaching myself Python * Online Advertising (Booking Campaigns)
I know how to do a lot, I just don't feel like I'm good at any of it. This is where I feel Jack of all trades (master of none) is an insult rather than a compliment.
Like the author I feel that if I apply somewhere else my skill level might not be up to par. It really is frustrating.
And yet, why would we need to be "Master" of anything?
One thing struck me in Hery's post: He did things. He accomplished. And many of these things he seemed to enjoy doing. How many of us here, with our fancy degrees and self-taught knowledge have lots of projects "on the side", always thinking "I'll do it when I got time" but never actually DOING anything? Like kids in front of a box full of LEGO, rummaging through the pieces, putting two of them together then going through it again,... In this age full of distractions (let's look at your reddit karma again, and are you sure your inbox is empty? maybe someone tweeted something interesting in the last five minutes), the value of your knowledge ain't "jack", your value as a developer lies in what you can accomplish.
Don't mind the bullshit job offers asking your for "ten years in java, 20 years in ruby and 50 years in BASIC (knowledge of COBOL a plus)", most companies would KILL to have someone as devoted (and versatile) as you.
Keep on!
http://alexkrupp.typepad.com/sensemaking/2012/09/program-abo...
Of course, this doesn't mean I think programmers shouldn't use Google or Stack Overflow, I use them all the time. However, the specifics of what you're Googling matter a lot. If asked to implement a Red-Black Tree and you have to Google that to get an idea of what it is (or to refresh your memory) that's one thing, but if you have to Google basic loops or "FizzBuzz level" basic discreet logic constructs to implement simple code, then that's a huge problem.
Lest anyone think this is unethical, do remember that the large majority of job postings are made by people who ask the impossible (a level of experience in new languages that basically make it accesible only the language developers) or the irrelevant. Use your own criteria to determine when this makes sense.
This will fix the problem of having a wide range of hacker skills and a portfolio of projects but not being able to make it through a Google inspired interview.
There's probably a Coursera or OCW course that might help but the key is you have to actually do the exercises.
1. dabble in everything and master nothing
OR
2. Specialize in one thing and never touch anything else again.
There's a bit of a middle ground. Have one (or two, or three) things you specialize in and develop great depth, coupled with a tremendous breadth of general knowledge of related things.
You could strive to be a "generalizing specialist" as they say[1] or a person with "t-shaped skills"[2].
"T people" are very highly valued, in at least some contexts[3].
[1]: http://www.agilemodeling.com/essays/generalizingSpecialists....
[2]: http://en.wikipedia.org/wiki/T-shaped_skills
[3]: http://chiefexecutive.net/ideo-ceo-tim-brown-t-shaped-stars-...
Bundler, gem, pip, npm, blah blah blah. It's a lot of stuff to grok if you want to get anything done in the 'right' way.
Much of my education was from a "get cool shit done" perspective, and I did. I had solid projects in an array (no pun intended) of languages but lacked some of the true, lower-level knowledge as a foundation.
Your mileage may vary, of course, but if I could start my CS education over again, that would be my advice to... myself..
I'll admit I'm a little confused, as my entry-level interviews never involved any questions about language or API trivia. If I had to write code, I could do it in any language I wanted and was comfortable with. And sometimes I wouldn't even have to write code, just discuss a problem and potential approaches. The solutions would never depend on library-specific knowledge.
Then you were lucky. A lot of interviewers can't get that far.
In short, I think you're doing it right and will end up better off than someone who focused on one language because that's what companies appeared to want.
I've had an interview or two over the years in which I surely lost out due to my inability to rattle off some bit of trivia about one thing or another, but it's probably for the best.
1) If the job was really so narrow that such a specific, rote depth of knowledge mattered I'd probably find it terribly boring.
2) If the interviewer is willing to write me off based on canned questions without actually conversing with me - the place where I feel I shine. I probably don't want to work for/with him/her.
Yes, there are surely exceptions to this, it's not a hard and fast rule, but as I said above it has worked out fine for well over a decade now.
It is really tough to strike a balance.
I have two suggestions:
Build an application in Clojure and in C/C++. IMO you should try a functional language (doesn't have to be clojure) and a lower level language. It could be a clojure webapp and a C++ opengl game... doesn't matter.
Here's something to get you started: http://nehe.gamedev.net/tutorial/lessons_01__05/22004/
I wouldn't worry about specializing just yet, just keep doing what you're doing, just up your difficulty level. Already you've done more than 50% of the programmers in the market (most know one language, like Java or C#).
Take some version of those classes (maybe OCW, edX, or Coursera) and you will be good to go — at least for technical interviews. If you like reading then Introduction to Algorithms by Cormen, Leiserson, Rivest, and Stein is the book that these courses cover.
Try this experiment: ask someone in school who just finished a hard-sounding class (that you haven't taken yet) to interview you based on knowing answers to things they learned in class. It should sound mostly greek to you. From your perspective, you don't stand a chance of knowing the answers. But, now you know that the delta between not knowing and knowing is one semester, or if you're brilliant, two nights of cramming.
My point is, there is very little delta in what is required to prepare for an interview and what is required to prepare for year-end exams in any given subject. You don't need a lifelong working knowledge of theory. You need enough immediate knowledge of algorithms to get you past the meat-grinder. Remember how you crammed in college? You can get by most of the time by cramming hard for the interview. Also, you get partial credit for thinking out loud about the answers you're considering giving, if you're anywhere within a mile of the correct answer, the interviewers will likely give you a passing grade on the question.
Once you're inside, most of those challenging questions, well, they'll likely never come up again. Just like the stuff you "learn" in college.
Source: In my previous life, I was part of a team of developers who interviewed people for technical positions. We were mean, ruthless interviewers. I've also been through the meat-grinder myself a few times.
Of course, even with such brief bursts of effort, you can "relearn" quickly by consulting various references and refreshing your memory, but it becomes difficult and scary to imagine what life would be like if we couldn't look up whatever we needed.
It'd be scary to work out math problems without pen and paper. It'd be scary to cross over the amazon without an airplane. Applies to every tool you use.
I'd like to think of Google as my secondary memory (HDD?). All I seem to have is RAM.
The first kind learns and learns deep. They are spooky good at it. They'll latch on to something and then follow it all the way down to its roots, learning it in tremendous depth to the point that their skill in it seems almost supernatural. After all of this, they say to themselves "now what can I build with this?" (Or find a place where an employer tells them this).
The second kind decides what they want to build up front and then pursues wide and varied avenues of technology on the path to this destination. They often have fascinating slivers of depth in certain areas but lack that magical seeming deep domain knowledge. These are the people more likely to identify as "self taught" with all of the downsides that come with that. They make up for this with ridiculous determination and a kind of sixth sense for what is possible if you try hard enough. Everything they know, they learn on the path to the destination.
Both can accomplish amazing things. You'll never hire one of the second kind. The second just isn't going to be able to show you pointer arithmetic on your whiteboard in your pet language.
I am multilingual, an autodidact and I love programming. I also have a gift (your 6th sense) for engineering in that I am able to visualize and analyze machines/systems by glancing over the designs or watching them work. Combined with soft skills and programming experience this has proven of great value in industrial settings where I am able to relate and connect the mechanical, software and other engineering departments.
A couple of years back I started working at a start-up doing robotics and machine vision. Due to lack of time and personal I had to teach myself everything from inverse kinematics, path planning to a solid knowledge of 2D and 3D machine vision. In less than a year I was developing and integrating 3D vision systems and steering industrial robots. Only after delivering that first project on my own did I allow myself to internalize my accomplishments.
I might not have a formal engineering degree, but being a jack of all trades has proven to be a high value asset. It's about finding an environment where your (broad) skills pay off.
Generalizations as the one above make it harder for people like me to start a career as I very much belong to the second group.
Also, I can show you pointer arithmetic in my pet language.
I'm curious about why you say "You'll never hire one of the second kind"?
How does one of the second kind fit into the world as an employed developer? This is something I'm struggling with currently.
tl;dr: A Google-like company would not have hired (someone like) Woz.
(1) Its double-hard because there are no shortage of people with tenacity who have the knack for doing things in a terrible way over and over. They all think they're in the former category.
I'd hire that person to do nearly anything. Sadly, not many interview processes are hip to github yet.
There are some positions where this obviously does work in your favour, but in general, you can be a junior in a bunch of jobs rather than a senior in one.
Maybe you won't hire the 2nd kind (as you say). Doesn't mean someone else will see the value in such background. Though there is an implicit message in your post. That all college trained programmers are the same. Which is downright wrong, due to there being a lot of different types of programmers. There are people who I wouldn't let near a database, but can really write some awesome C++. Or those who are awesome at writing web crawlers, but suck at making effective CRUD apps. Or maybe that guy who is a genius at VB.NET, and carries the weight of a whole company on his back (maybe he taught himself). You wouldn't hire those? Then you wouldn't hire yourself.
I am a college trained programmer, but I do identify strongly as the second type. When I really think about it, I'm forced to admit that if I was in charge of a large company's HR policy, that policy would probably prevent hiring someone like me for all but the most junior of positions.
A smaller company might have a lot more freedom in this regard. "You'll never hire one of the second kind" might better have been said as "big companies never hire the second kind".
But any big company HR dept. would hire them in a heartbeat.
Disclosure: I don't have a college degree. But I don't want to work on your big company either. (:
Too many companies place emphasis on degrees instead of capabilities. I might not have a degree but that's because I thrive and learn a lot easier when I'm teaching myself as opposed to absorbing and listening to someone else drone on about things that might not interest me. At least when you're self-taught you only learn the parts that matter to you and so, you're more likely to learn them correctly.
For instance, one of my good friends is one of the smartest programmers I have ever met. I've been bothering him to come down to our hackerspace (shameless plug: http://heatsynclabs.org) for YEARS, and he recently started obliging.
I came in one day and saw him sitting at a workbench hovering over a microscope.
Me: "Hey, Trav, what are you doing?"
Him: "Sharpening knives."
---
Ah, yes, of course. Because most people who want to sharpen a knife head down to the lab with a bottle of aluminum oxide because they want to use the microscope.
In the month since then, he has become an encyclopedia of knives. Every material, every manufacturer, every sharpening technique. I was at his house the other day picking him up for a road trip to Colorado, and his workshop is filled with sharpening stones (and rods) and different knives. On the ~9hr drive to CO, we went back and forth, me soaking up seemingly everything I could about knives.
Next month he's going to present at our little Tedx style event at the lab. (Members present on a topic they're knowledgable about).
But this obsessive learning technique isn't limited to knives. Back when we were roomates, he decided that he wanted to build a stepper motor controller, and I don't mean "assemble the kit from adafruit". He wanted to build a controller for the type of ultra-high-performance DC stepper motors found in hobby airplanes and helicopters because he wanted to build a quadcopter, but didn't want to use somebody else's electronics design. I spent that summer learning, by proxy, about control theory, what is back EMF, what do "closed loop" and "open loop" mean? How do motor controllers work, and why?
--
Examples of my friend aside, I think that your #2 is enabled by the traits that make up your #1, or that they can at least feedback into each other. You get the super broad domain knowledge because you've gone really, really deep into a few subjects, and can intuit most of the rest of the domain because of it.
When a company is hiring, would they rather hire someone who can get by or a fluent speaker?
I think there is certainly a breath and depth balance to be had and I think you are correct in seeking more depth. A deep understanding of one language will allow you to more quickly gain depth in other languages.
And have fun!