141–150 of 268 posts
>Four people need to cross a rickety bridge at night. Unfortunately, they have only one torch and the bridge is too dangerous to cross without one. The bridge is only strong enough to support two people at a time. Not all people take the same time to cross the bridge. Times for each person: 1 min, 2 mins, 7 mins and 10 mins. What is the shortest time needed for all four of them to cross the bridge? 17 minutes, if you…
Earlier quoted context omitted.
RegEx is just ludicrous a general requirement to "program" as anything else. I've never particularly wanted it to write the mathematical models I work with. I can think of just a single instance where I've used one in the last year and that was to display integers as ordinal numbers (hardly a sizeable task). Every job needs a spec. Every spec should inform the interviewer and the interviewee of the skills and compete…
Agreed. I can write a regex the (very) few times I need one, but it generally entails me looking up a cheat sheet to get the appropriate character classes. If you were to put me in front of a whiteboard I would flub the most simple of tasks (from the original post, "{(.*)}", I think? Did we mean to include whitespace, and does . translate properly? Because that's partly language dependent when it comes to white space…
EDIT: I don't care if you ever actually use regex in a program. You should learn regex just as a part of using a text editor.
For example, suppose I want to write a bit of repetitive code like this:
x = x + vx * t + ax * t * t / 2;
y = y + vy * t + ay * t * t / 2;
z = z + vz * t + az * t * t / 2;
However, with regex search and replace, I first type
x
y
z
And replace with the pattern: $1 = v$1 * t + a$1 * t * t / 2;
And now that I've been doing it for a little while, it's second nature. It's how I write lots of code.
Earlier quoted context omitted.
Actually I think graph theory is pretty important. For example many programming contexts have to deal with dependencies, and often dependencies form a directed acyclic graph. Understanding that will aid in writing better, more reliable code. Path finding is also pretty important, especially if you want to make a game.
That's great if you're a game AI programmer (an incredibly small group) or you're creating Yet Another Dependency Loader (hey, I guess will only have 100 frameworks to manage modules, you'd better create your own as well). You know what I really wish? Programmers would spend 1/100th of that algorithm studying on learning to write readable, maintainable code.
> I’ve been programming for 18 years now. Then congratulations, you are a programmer! Despite what you'll hear from people peddling various flavors of Kool-Aid, "programmer" isn't a personality type. It's a job description. If you program, you are a programmer, end of line, full stop. Don't let anyone convince you otherwise.
>If you program, you are a programmer I agree.
I am an antiprogrammer though.
I think some of it comes from our notion of human intelligence being universally applicable to all problems. Puzzles and chess are often used as a proxy for that. The thinking goes is that if you're smart then you'll be good at puzzle solving. If you're smart then you'll be a good programmer. It's not really something that has a lot of evidence for. One of the best career advice I've received is to interview with lot…
There is some evidence in psychology that many seemingly unrelated types of intelligence are correlated with each other. For example there is correlation between verbal and spatial reasoning ability. Sure, there might be people who can solve differential geometry problems in their head but have terrible language skills, but those people are outliers.
Whether this has relevance to hiring programmers is debatable, but preferring intelligent candidates isn't an unusual idea. Law, medical, and dental schools base their selection on what is essentially a verbal reasoning test (LSAT, MCAT, DAT) though it's hard to imagine that verbal reasoning is the most important part of being a dentist. They follow the same thinking.
I don't hate puzzles, but my brain just refuses to work on something that is not important to me. That's why I can't play go/chess well, I can't do sudoku and I can't solve algorithmic puzzles. Even when working on a real algorithmic problem, my brain just refuses to analyze whether something should be x or x+1. Those are things I can easily try and see. I had a number of technical interviews last month and the concl…
Another Human Resources blunder. I really would like to ask them, where and when am I going to use this in one of your ongoing project? If the answer is not related to the project, there is something wrong.
Earlier quoted context omitted.
Actually I think graph theory is pretty important. For example many programming contexts have to deal with dependencies, and often dependencies form a directed acyclic graph. Understanding that will aid in writing better, more reliable code. Path finding is also pretty important, especially if you want to make a game.
Agreed. Some people say you'll only use it in games or AI or something fancier, but that's not entirely true. I work with what would be considered pretty boring enterprise software, and yet I once solved a pretty big problem using graph algorithms. That actually earned me a good reputation among my coworkers.