Live data from Hacker News

Ask HN: Should I quit trying to be a programmer?

news.ycombinator.com

51–60 of 69 posts

Re: Ask HN: Should I quit trying to be a programmer?

#51
post #3

Objectively, I would say that the problem you struggled with this morning should be doable by someone in comp sci 102 (and probably comp sci 101). That you're struggling with something like this, suggests that you're very out of practice and really haven't done any significant work recently (or at least not in Python). That doesn't mean you're unhirable, but it does mean that you're going to need to spend a lot of ti…

I've been practicing interview questions everyday for the past few months on and off in Python. I've been trying to prepare for technical interviews. I run into problems with almost any problem I attempt and I was even worse when I started. Even something as simple as recursive solution of fib sequence was undoable until recursion clicked more.

I chose cs because I like problem solving, having a concrete end result and because it's a way to make good money without an extreme amount of years in school.

Re: Ask HN: Should I quit trying to be a programmer?

#52

Don't sit down in front of your computer until you have a very good idea of how your algorithm is going to work and how to code it. Sit down in front of a piece of paper with a pen. Draw diagrams to visualize the data structures that you're working with. Sketch different corner cases (for example, arrays of odd and even length). Informally (playfully) derive an algorithm to do what you want and convince yourself that…

I have been doing that, but as I said in response to another comment, I don't see what I'm missing or what's wrong until I start to code it. Either the test cases fail or I run into something that's easy to describe in pseudocode, but more difficult to describe in real code. It seems, at the time of using the paper and pencil, I would be trying to know what I don't know because it always seems fine before I start to code it and then I discover its not.

Re: Ask HN: Should I quit trying to be a programmer?

#53

If you couldn't even do half your coding assignments, you're probably fucked. That indices edge case thingy with that problem is an annoying thing that trips me up too, but here you're saying you couldn't do half your coding assignments. Let's say you want to make a single player Tetris game right now, on a platform of your choice. Could you do that?

It's not that I couldn't, but more so that I didn't. Maybe, I couldn't as well, but of those that I had to do I ended up being ok.

Single player Tetris, maybe not. I don't know graphics libraries. Maybe, if I just continually printed a 2d array on screen then I could figure out the logic, I think.

Re: Ask HN: Should I quit trying to be a programmer?

#54
post #19

Well, I think alexanderdmitri's advice of looking for answers to coding problems on places like Stackoverflow is great advice and I'd like to expand on it a bit. It's easy to get sucked into a coding problem and fight with it for days like it's a personal challenge to your abilities. That can turn into a habit. It did for me. Screw that. Admit you have a problem and then get over it. The goal of working is to produce…

I agree with what you're saying, but I struggle with knowing when to look up answers. If I'm supposed to be able to solve any given problem on my own then looking it up won't get me the problem solving practice I need. I don't know the line of "I need to keep at it for more time" and "I can't solve this better to look it up" especially since I get stuck with almost every problem. It seems best case I learn how to do that one particular problem (for as long as I remember the lesson), but then will most likely get stuck on the very next problem I encounter.

Re: Ask HN: Should I quit trying to be a programmer?

#55
post #32

I struggled on the exact same problem on leetcode - It took me over three days of obsessive coding to finally get something that worked (even then it was so hacky that it was non-deterministic, but somehow it passed the tests) In the end my point is that sometimes problems will take a long time to figure out, and that’s okay as long as you’re willing to commit the time. One thing you’ll learn with more experience is…

I don't mind the struggle so much as the uncertainty. Will I be able to get a good job? Will I be good enough to keep it? Will I be good enough so I have enough free time to enjoy other parts of life? If I had a definite yes to all those questions, I wouldn't really mind as it would be the normal process of learning. But going through all this just to fail or plateau at a point where I have to work 12 hour days everyday to do what the guy next to me is doing in 8 hour weekdays is not the life I want.

Re: Ask HN: Should I quit trying to be a programmer?

#56

that problem is a red hard problem so don't feel too bad but I don't understand your brute force solution? the brute force solution is the last step of merge sort and then jumping to n//2

2 pointers, i and j, one for each array. I would have a while loop run for length of the arrays / 2 times. I would increment one of the pointers with each iteration based on which array had the next biggest number. When the while loop was done one of those pointers would be pointing the median if the length of both arrays summed to an odd number and I would return it. If the length was even, I would need to get the next biggest number from either array and average it with what would be the median if it was odd and then return that.

Re: Ask HN: Should I quit trying to be a programmer?

#57
post #47

I've a few years of experience tutoring programming. From what often see and from reading your description, it sounds like your problem is "need better planning before jumping to writing a code". Programming is akin to building a house. Once the blueprint is figured out, the actual act of building (putting bricks together, etc) is actually pretty straightforward. The key though, is good the planning. By good planning…

I actually do go through the 5 steps you mentioned, but the problem is I don't see parts of the algorithm I'm missing until test cases fail or until I'm actually translating to code. The need to make what I'm thinking precise and understandable to the computer or the oversight of edge cases or, sometimes, an entire set of cases I didn't have in mind originally when coming up with the high level solution, evades me un…

>>The need to make what I'm thinking precise and understandable to the computer or the oversight of edge cases or, sometimes, an entire set of cases I didn't have in mind originally when coming up with the high level solution

To me this sounds like you should spend more time in the planning phase. Sounds like your plan needs to be more detailed and concrete. If you hadn't yet come up with a high-level solution, jumping straight to code wouldn't help either, it'll only make it more confusing.

>>but I'm not sure what to do with it if the ideas and logic simply don't come to my head.

What sort of ideas and logic are you specifically having problem with? If they're about algorithms, try reading more algorithm books (Thomas Cormen's Introduction to Algorithm is really good), do more practice programming (I used to practice a lot here https://practiceit.cs.washington.edu/). In general I'd suggest try to see more problems where the solutions are available, but don't immediately see the solutions. Try to do it yourself first.

Re: Ask HN: Should I quit trying to be a programmer?

#59
post #47

Earlier quoted context omitted.

I actually do go through the 5 steps you mentioned, but the problem is I don't see parts of the algorithm I'm missing until test cases fail or until I'm actually translating to code. The need to make what I'm thinking precise and understandable to the computer or the oversight of edge cases or, sometimes, an entire set of cases I didn't have in mind originally when coming up with the high level solution, evades me un…

>>The need to make what I'm thinking precise and understandable to the computer or the oversight of edge cases or, sometimes, an entire set of cases I didn't have in mind originally when coming up with the high level solution To me this sounds like you should spend more time in the planning phase. Sounds like your plan needs to be more detailed and concrete. If you hadn't yet come up with a high-level solution, jumpi…

The thing is I have no idea I need more planning. When I start to code the solution I've come up with seems genuinely complete and correct. It's only when the incorrectness hits me right in the face, usually in the form of test cases failing or not being able to code something I thought I could, that I realize I didn't have it.

To be concrete, yesterday I tried to solve this question: https://leetcode.com/problems/wildcard-matching/ I spent 45 minutes on the planning phase which would be the entire time I'd have for the problem in an interview. I had some pseudocode, thought through it, tried an example or two and then decided to code it up. As I did I realized a few more examples which I added in. Finally, I had some code that seemed even more correct than the code I thought was already correct. I run it and test cases fail. I spent 2.5 hours in total trying to get them all to pass without realizing the central issue of the question is what to do when you hit a * character. The necessity to try all the combinations of the string after a * doesn't not occur to me in 2.5 hours; I kept tweaking for specific cases I was failing. I ask a friend about the problem and in less than two minutes he realizes you need to try all combinations.

>>What sort of ideas and logic are you specifically having problem with?

It seems everything. Sure, some problems turn out to have an algorithm that I didn't know about it. Like the other day I was trying to do a problem that basically needed topological sort and I never really learned top sort. But then I read in the solution in CTCI that it's reasonable to derive that on one's own in a 45 minute interview so there goes that. More generally, it just seems when a problem reaches a certain level of difficulty my brain simply can't solve it. I suspect it's an intelligence thing. I just don't have a high enough IQ to get passed a certain point.

I will look at the resources you mentioned.

Re: Ask HN: Should I quit trying to be a programmer?

#60
post #59

Earlier quoted context omitted.

>>The need to make what I'm thinking precise and understandable to the computer or the oversight of edge cases or, sometimes, an entire set of cases I didn't have in mind originally when coming up with the high level solution To me this sounds like you should spend more time in the planning phase. Sounds like your plan needs to be more detailed and concrete. If you hadn't yet come up with a high-level solution, jumpi…

The thing is I have no idea I need more planning. When I start to code the solution I've come up with seems genuinely complete and correct. It's only when the incorrectness hits me right in the face, usually in the form of test cases failing or not being able to code something I thought I could, that I realize I didn't have it. To be concrete, yesterday I tried to solve this question: https://leetcode.com/problems/wi…

>>I spent 2.5 hours in total trying to get them all to pass without realizing the central issue of the question is what to do when you hit a * character. The necessity to try all the combinations of the string after a * doesn't not occur to me in 2.5 hours;

The fact you kept trying for 2.5 hours shows you are persistent -- an awesome ingredient to be a great programmer. In my opinion, you shouldn't blame yourself for not being able to solve that particular wildcard-matching problem. I think it's a typical "interview problem". I personally don't think "interview problem" is a good measure of a programmer because: 1. some people are more gifted in the thinking required to solve such problem. 2. if you practice a lot, basically you get better at it. It's like there's a certain pattern to such problems that you can learn. (think of it as similar to SAT)

>>Sure, some problems turn out to have an algorithm that I didn't know about it.

I'm not suggesting you need to know a lot of algos to be a great programmer. You just need to be familiar with the important ones such as linked list, hash map, binary tree, etc. Cos even at places like Google, they wouldn't really ask interview questions where you need to know anything unconventional. What I'm suggesting is that you learn to solve problem by reading solutions to existing algo problems, make sure you understand it, and try to re-implement it.

>>I just don't have a high enough IQ to get passed a certain point.

From your comments, it seems you think you have to be good at "interview problems" or what I like to call "algorithmic-thinking" to be a good programmer. I totally understand that perspective as most US tech companies' screening process involve such problems. I'm telling you from experience though, that computer science is much more than just "algorithmic thinking". There is the field of system where the main challenge is to envision how all the large number of components collaborate and work together (i.e. OS, distributed system). There is also the field of frontend web programming. Frontend involves the skill of implementing something that is visually aesthetic or implementing a web according to the design document. There's also product management role, where you have to understand the how the thing works but you don't have to go too technical. And many more.

In short, there are so much more in the CS than just "algorithmic thinking". Don't be discouraged. Try to figure out where your interest and talent intersect, work hard on it, and don't easily give up :)

Post reply on HN