4 ms·

As a self-taught developer these stories scare me. I don't know the ins and outs of programming fundamentals, but I know how to program and I am really efficien

As a self-taught developer these stories scare me. I don't know the ins and outs of programming fundamentals, but I know how to program and I am really efficient in what I do as well. I've got big ideas, I have drive and vision and I think technical interviews can have the reverse effect of attracting real people. For what I lack in low-level understanding, I more than make up for it on a higher level. Ask me to build something as a whole, don't ask me to solve mathematics questions and other unrealistic junk questions. The biggest takeaway from this post is definitely this: In my experience, when we are programming on the job, we're given the problem and we have time to think about it. We have time to research possible solutions, we have time to try stuff out that we know will most likely fail, and we can wait until we have something decent before we show it to our colleagues ^THIS. One hundred times over. How is putting someone on the spot to build something and build it perfect a good test of their capabilities and skills? That's not even how it works in the real world.

philwelch 13y ago
You're implying that low level CS knowledge plain isn't important in a developer role. Perhaps in some cases it isn't, but lacking low level CS knowledge is very limiting in a technical role and there are valid reasons employers might emphasize technical chops. There exist very good developers with drive and vision who have a strong grasp of technical fundamentals and can still manage to pass technical interviews. Why wouldn't you want to hire them? No one expects interview code to be "perfect", especially not for your first answer. Thinking about it aloud and going down a false path or two rather than trying to write a perfectly optimized solution first time is what you're supposed to do and a good interviewer will encourage that. On the other hand, you should also be able to get onto a fruitful path rather quickly, or at least when you get there, you should be able to follow it easily.
quanticle 13y ago
>For what I lack in low-level understanding, I more than make up for it on a higher level. Ask me to build something as a whole, don't ask me to solve mathematics questions and other unrealistic junk questions. Without the math, how do you know that your solutions are any good? How do you know that the algorithm you sketched out on the whiteboard will work on the 1,000,000 records that we have in production in addition to the 5 record toy example that you worked out? I mean, sure, I agree that brainteasers are in appropriate. Knowing why manhole covers are round or how M&Ms get their candy shell tells me nothing about your programming ability. But basic math and algorithms? They're a lot more important than you think. Knowing Big-O notation, various kinds of basic algorithms and a good assortment of data structures lets me know that you can evaluate a solution and find potential flaws and bugs. How is putting someone on the spot to build something and build it perfect a good test of their capabilities and skills? There's a difference between perfect and working. I've never had an interviewer ask me for perfect code. Not at Amazon. Not at Google. Not at Facebook. I have, however, been asked for working code. The code doesn't need to be 100% bug free, but it should be syntactically correct and should solve the problem in a reasonable fashion (e.g. without using inordinate time or space). Frankly, I like technical interviews a lot more than the alternative, which increasingly boils down to, "Make me a webapp and we'll evaluate your code." I'm sorry, but if I wanted to make a webapp for you on my own time, I also want to get paid for it. Even now, when I'm single and living alone, I have a hard time motivating myself to do homework problems. I can't imagine having to do something like that when I'm married and have children.
- cpprototypes 13y ago
  If someone is married and has children, then it's likely they've been working for a while (for example, assuming a typical graduation at 22 and kids at 30, that's 8 years in the industry). In that situation, technical interviews require a lot of time preparation. It would require looking at old college textbooks/notes, doing practice interview questions, etc. The amount of time required is probably about the same as a "make a webapp".
- jebblue 13y ago
  >> Without the math, how do you know that your solutions are any good? He probably does it the same way you do, idea, code, build, test, analyze.
  - XorNot 13y ago
    Or he realizes he doesn't understand the hard core mathematical basis, but knows to go looking for the most efficient algorithms for a given problem type. The history of computing is largely dominated by software which got done, not done perfectly.
  - mmorett 13y ago
    I'm torn on this. I get what quanticle is saying, that Big-O is very important. I've developed an appreciation for it even if I didn't take CS in college (I took the redheaded bastard stepchild major of CIS). quanticle is suggesting there is a purposeful, formal means of discussing and identifying performance, irrespective of how it's measured/profiled or addressed. Here's the rub: why don't job openings eliminate the other requirements and just put Big-O (and a language) as the two must have items on the list. Keep it short. Eliminate the History majors, the non-college types and the CIS (almost but not good enough) types. That, more than any FizzBuzz, should weed out the chaff instantly. If it's that important to that specific job, then just say so explicitly. Help folks self-filter themselves out. Let's just hope getting in the door with that Big-O knowledge isn't wasted on run of the mill CRUD apps.
  - DigitalSea 13y ago
    Yep, that's exactly how I do it. I've seen people use whiteboards and pens and paper to solve problems, but nothing solves a problem like tactfully tackling it head on and persisting until you solve it. Having said that, some people work better writing down their problems on a whiteboard and others physically solving them. In my day-to-day I try and avoid writing as much code as possible. If someone else has solved the problem, I'll read through their code and understand it, then implement. Developers at the end of the day are hackers. I think as long as you know how and what to Google, then you're more than capable. The difference between a good developer and a bad developer isn't knowing all the answers it's knowing where to find the answers when you need them whether that be documentation, a Google search or even a physical book. Because lets be honest here. In the day-to-day life of a developer what percentage of developers actually solve their problems manually using their brains as opposed to finding the solution on Stackoverflow, forum or blog post? I'd be willing to bet a large percentage do. When I get stuck on something I hit Google, in an interview if they were to take into account your problem solving skills in the form of a Google search, then that would be more than fine. But I am willing to bet most interviews don't allow you to search for answers.
mmorett 13y ago
"In my experience, when we are programming on the job, we're given the problem and we have time to think about it. We have time to research possible solutions, we have time to try stuff out that we know will most likely fail, and we can wait until we have something decent before we show it to our colleagues" ^This * 2 :-) That's exactly how it played out on this thread in real life. Let me explain. philwelch mentioned something about using anagrams as simple example to test for coding knowledge. My first attempt was a solution to palindromes. (Seriously...I totally botched the interpretation of the problem). Elsewhere in the thread, typicalrunt sketches out some Ruby to show the answer but the crucial piece was him mentioning "sort(word1) == sort(word2)". I didn't know that. Language aside, I get it now, but I didn't then. If you don't know that, all the knowledge of language syntax in the world won't help. So, just sort two strings. Cool. Except, I had never sorted a single string. It just never came up in day to day work. A quick peek over on StackOverflow yielded two bits of information I needed (I'm doing this in Java). 1. Convert the string to a charArray (something else I never used). 2. Sort the charArray using Arrays.sort() With those pieces in place, the solution became evident. But....I'm doing this at home with the TV on, relaxing, with nothing on the line, no one looking at me, the ability to research things, and generally no pressure at all. I was just curious on how to get the answer. Change that to a job on the line, typicalrunt's advice/pseudocode not available and folks staring at you, and it's not going to end up the same way. I drew a blank at home. I'd definitely draw a blank in an interview. Elasped time to solution (actual coding): < 1 minute. With solution in hand, am I now somehow "better" as a developer? I think not. I did what I would do on the job: research when needed and apply it to the problem at hand. I could be faulted for not ever having used toCharArray(). Fair enough. But in the grand scheme of things, did it matter? Heck, there's plenty of pieces of the Java language I don't use daily or not at all. Anyways, I just wanted to share how this played out.

philwelch 13y ago

You're implying that low level CS knowledge plain isn't important in a developer role. Perhaps in some cases it isn't, but lacking low level CS knowledge is very limiting in a technical role and there are valid reasons employers might emphasize technical chops. There exist very good developers with drive and vision who have a strong grasp of technical fundamentals and can still manage to pass technical interviews. Why wouldn't you want to hire them? No one expects interview code to be "perfect", especially not for your first answer. Thinking about it aloud and going down a false path or two rather than trying to write a perfectly optimized solution first time is what you're supposed to do and a good interviewer will encourage that. On the other hand, you should also be able to get onto a fruitful path rather quickly, or at least when you get there, you should be able to follow it easily.

quanticle 13y ago

>For what I lack in low-level understanding, I more than make up for it on a higher level. Ask me to build something as a whole, don't ask me to solve mathematics questions and other unrealistic junk questions. Without the math, how do you know that your solutions are any good? How do you know that the algorithm you sketched out on the whiteboard will work on the 1,000,000 records that we have in production in addition to the 5 record toy example that you worked out? I mean, sure, I agree that brainteasers are in appropriate. Knowing why manhole covers are round or how M&Ms get their candy shell tells me nothing about your programming ability. But basic math and algorithms? They're a lot more important than you think. Knowing Big-O notation, various kinds of basic algorithms and a good assortment of data structures lets me know that you can evaluate a solution and find potential flaws and bugs. How is putting someone on the spot to build something and build it perfect a good test of their capabilities and skills? There's a difference between perfect and working. I've never had an interviewer ask me for perfect code. Not at Amazon. Not at Google. Not at Facebook. I have, however, been asked for working code. The code doesn't need to be 100% bug free, but it should be syntactically correct and should solve the problem in a reasonable fashion (e.g. without using inordinate time or space). Frankly, I like technical interviews a lot more than the alternative, which increasingly boils down to, "Make me a webapp and we'll evaluate your code." I'm sorry, but if I wanted to make a webapp for you on my own time, I also want to get paid for it. Even now, when I'm single and living alone, I have a hard time motivating myself to do homework problems. I can't imagine having to do something like that when I'm married and have children.

cpprototypes 13y ago
If someone is married and has children, then it's likely they've been working for a while (for example, assuming a typical graduation at 22 and kids at 30, that's 8 years in the industry). In that situation, technical interviews require a lot of time preparation. It would require looking at old college textbooks/notes, doing practice interview questions, etc. The amount of time required is probably about the same as a "make a webapp".
jebblue 13y ago
>> Without the math, how do you know that your solutions are any good? He probably does it the same way you do, idea, code, build, test, analyze.
- XorNot 13y ago
  Or he realizes he doesn't understand the hard core mathematical basis, but knows to go looking for the most efficient algorithms for a given problem type. The history of computing is largely dominated by software which got done, not done perfectly.
- mmorett 13y ago
  I'm torn on this. I get what quanticle is saying, that Big-O is very important. I've developed an appreciation for it even if I didn't take CS in college (I took the redheaded bastard stepchild major of CIS). quanticle is suggesting there is a purposeful, formal means of discussing and identifying performance, irrespective of how it's measured/profiled or addressed. Here's the rub: why don't job openings eliminate the other requirements and just put Big-O (and a language) as the two must have items on the list. Keep it short. Eliminate the History majors, the non-college types and the CIS (almost but not good enough) types. That, more than any FizzBuzz, should weed out the chaff instantly. If it's that important to that specific job, then just say so explicitly. Help folks self-filter themselves out. Let's just hope getting in the door with that Big-O knowledge isn't wasted on run of the mill CRUD apps.
- DigitalSea 13y ago
  Yep, that's exactly how I do it. I've seen people use whiteboards and pens and paper to solve problems, but nothing solves a problem like tactfully tackling it head on and persisting until you solve it. Having said that, some people work better writing down their problems on a whiteboard and others physically solving them. In my day-to-day I try and avoid writing as much code as possible. If someone else has solved the problem, I'll read through their code and understand it, then implement. Developers at the end of the day are hackers. I think as long as you know how and what to Google, then you're more than capable. The difference between a good developer and a bad developer isn't knowing all the answers it's knowing where to find the answers when you need them whether that be documentation, a Google search or even a physical book. Because lets be honest here. In the day-to-day life of a developer what percentage of developers actually solve their problems manually using their brains as opposed to finding the solution on Stackoverflow, forum or blog post? I'd be willing to bet a large percentage do. When I get stuck on something I hit Google, in an interview if they were to take into account your problem solving skills in the form of a Google search, then that would be more than fine. But I am willing to bet most interviews don't allow you to search for answers.

mmorett 13y ago

"In my experience, when we are programming on the job, we're given the problem and we have time to think about it. We have time to research possible solutions, we have time to try stuff out that we know will most likely fail, and we can wait until we have something decent before we show it to our colleagues" ^This * 2 :-) That's exactly how it played out on this thread in real life. Let me explain. philwelch mentioned something about using anagrams as simple example to test for coding knowledge. My first attempt was a solution to palindromes. (Seriously...I totally botched the interpretation of the problem). Elsewhere in the thread, typicalrunt sketches out some Ruby to show the answer but the crucial piece was him mentioning "sort(word1) == sort(word2)". I didn't know that. Language aside, I get it now, but I didn't then. If you don't know that, all the knowledge of language syntax in the world won't help. So, just sort two strings. Cool. Except, I had never sorted a single string. It just never came up in day to day work. A quick peek over on StackOverflow yielded two bits of information I needed (I'm doing this in Java). 1. Convert the string to a charArray (something else I never used). 2. Sort the charArray using Arrays.sort() With those pieces in place, the solution became evident. But....I'm doing this at home with the TV on, relaxing, with nothing on the line, no one looking at me, the ability to research things, and generally no pressure at all. I was just curious on how to get the answer. Change that to a job on the line, typicalrunt's advice/pseudocode not available and folks staring at you, and it's not going to end up the same way. I drew a blank at home. I'd definitely draw a blank in an interview. Elasped time to solution (actual coding): < 1 minute. With solution in hand, am I now somehow "better" as a developer? I think not. I did what I would do on the job: research when needed and apply it to the problem at hand. I could be faulted for not ever having used toCharArray(). Fair enough. But in the grand scheme of things, did it matter? Heck, there's plenty of pieces of the Java language I don't use daily or not at all. Anyways, I just wanted to share how this played out.