291–300 of 309 posts
Break down the problem into smaller ones you think you can solve and start from there, the more practice at this the better you get at solving future problems. Maybe you even turn out to be really good at this and take up amateur theoretical CS in your spare time.
Earlier quoted context omitted.
That crosses into personal attack. Please review the guidelines and don't do that here. https://news.ycombinator.com/newsguidelines.html
Every time I see a deleted comment and a reply like that, I get so morbidly curious what was said, and yet, I've _been_ a moderator on a forum, so I know for certain that reading it would never make my mood any _better_, just worse. Is this just me? I know it's self destructive to seek out negativity like that, but that curiosity just won't go away.
Read mine. There is more to what's going on than meets the eye. And if you email me (see profile), I'd be happy to illustrate just how carefully Dan controls his image.
After all, see your language here. There's nothing wrong with being curious. That's the whole point of HN.
Earlier quoted context omitted.
Why would you expect the modern application developer to even know what ASCII is? There is a chance I wouldn’t know what ASCII encoding was if my exposure to programming didn’t start in the 8 bit era. C is foreign to a lot of self taught programmers.
In this modern time, no one needs to know what the ASCII code for @ is, but I think it is logical to expect people to know that some encoding exists and that letters can be mapped to numbers. Also, all the ASCII you need to know to solve the problem is explained at length in the problem description.
...But if you give me a second...
Now that I've typed "ascii character codes" into google, I can tell you how to convert between an int and a character.
You don't have to memorize everything. Well over half of our job is knowing how to find information quickly.
Honestly, I'm appalled by some of the stories being shared in this thread; smug interview panels pressure-cooking candidates as they try to whiteboard obscure CS gotchas is a system perfect only for assholes and masochists. I've now run three tech companies and hired dozens of developers by having really intense, thoughtful conversations with them. I asked them to tell me war stories and encouraged them to share insi…
> It makes me question how I was hired in the first place. It is called imposter syndrome. It is very real and very common. As a JavaScript developer I encounter this among my peers all the damn time. First, consider what it takes to be a professional software developer. The requirement is to pass a one time drug test and successfully answer questions in a 30-90 minute interview. Done. Consider, conversely, all other…
> The requirement is to pass a one time drug test Wait what? Where do you live that software developers are drug tested?
Honestly, I'm appalled by some of the stories being shared in this thread; smug interview panels pressure-cooking candidates as they try to whiteboard obscure CS gotchas is a system perfect only for assholes and masochists. I've now run three tech companies and hired dozens of developers by having really intense, thoughtful conversations with them. I asked them to tell me war stories and encouraged them to share insi…
I liked this approach of hiring.
Me too. I even invented slightly famous stuff. It's like this: There's reality. Then there's a map of reality which is, for obvious reasons, pretty fucking far from reality. Then there's the map of the map, which is delusionoid-squared. In this case you are dealing with the level2 map. Most of us don't take it too seriously.
Let me paraphrase:
"The map is not the territory. It's not even close."
Earlier quoted context omitted.
I've seen so many projects where the developers have taken this to heart way too much. The problem is they use it as an excuse to give up after stage 2 thinking stage 3 can come along when it actually becomes a problem. The thing is that performance issues tend to creep up on you so slowly that you don't realise it until you have a very important client with tons of data screaming at you to fix it now. To fix it then…
I'm not sure you two actually disagree, but rather that you're thinking on different scales. Make it right, then make it fast is usually talking about specific snippets of code, rather than the whole program, so your whole program should be "made fast from the start" because you went through the process of making it right and then making it fast on the components themselves.