Jacquass12321

I assumed they all starved because one guy never passed the fork.

"Weird, my cd drive just opened up."

Firstly and most importantly, Thanks to rebase I'm constantly working against the most recent mainline, merge pains are reduced by frequently dealing with smaller rebase merges instead of trying to do one massive merge at the end when I'm finished with a longer life task that might last a week or two. The more often you merge the less painful it is.

Secondly there's the cleaning part of history involving squashing. I believe the issue with your viewing the merge history of the main line will miss out on changes that were able to be introduced fastforward without a merge. And frankly no one else on the team cares that I committed 6 times in the process of one task, they want to see all the code relevant to that task, and ideally it's all in one change set.

There's a pretty reasonable summary over here http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/

For certain teams rebase just makes a lot of sense.

The discussion of focusing our scope and becoming more of a single stack shop has certainly come up, and some engineers are in favor of it because it certainly has benefits. Company wide practices can easily apply to all projects, engineering resources are far easier to exchange when everyone uses the same skill set, and knowledge gains are applicable to all projects.

It's a lot harder for my custom tools I write for managing a Perl/WinForms/.NetMVC website to provide benefits for the guys downstairs working on embedded systems in c++.

Personally I prefer the variety of a polyglot shop but I can see where the appeal is to streamline company wide and specialize.

Our spread of technologies is mostly due to self motivated engineers learning new technologies and working on gaining experience to the point where we feel comfortable charging a client to develop a solution using that technology. For example, 4 years ago we'd done no mobile development. Around that time a few engineers dove into personal projects in Android and IPhone development and we've since released several products for both platforms. This was completely facilitated by employee efforts and interests. If no one wants to work on your technology stack we probably won't offer a solution and will just help you find another company.

Also the value versus risk ratio for Diablo 3 accounts is probably better then trying bank accounts. The risk for attempting entry into a bank account is FAR higher then for a Diablo 3 account.

If you want to complain about something you should be complaining about websites that when you password recover e-mail you your old password. THAT is a sign of plain text password storage.

The importance of case sensitivity is dramatically overblown. An appropriately long password is still just as safe regardless of case sensitivity.

http://en.wikipedia.org/wiki/Password_strength#Random_passwo...

If you examine the length versus entropy chart you'll notice that you get identical results with only 2 more characters in your password for case insensitive.

http://xkcd.com/936/ also seems relevant.

This really seems like mountain out of a molehill, although I think everyone should get 2 factor authentication whenever it's an option. I don't see any correlation between someone choosing to use caps insensitive passwords and clear text password storage.

I'd keep track of user requests and things you've learned from the application, if you ever have enough to justify a new game put out a sequel or a new version. Until then I'd feel free to work on a new project.

Only speaking for myself, but I wouldn't touch java if it wasn't the language for android development. I'm hard pressed to believe the attention and new developer interest android is bringing to java will hurt the language.

Thankfully my crypto course came along a few years later and restored my faith in math.

Isn't that what his university degree should have already covered?

Do you think this accurately reflects the working conditions of a developer?

Who said anything about trying to simulate a normal development day? This is about finding out some of their thought processes and if they can solve an exceedingly simple coding problem.

They may blank, they may freeze and they may just be the type of person that reflects on an issue for a while before the set out to code.

Where did they say you can't reflect on the issue? That's exactly what they want is you reflecting on the problem and describing how you'd go about solving it.

If someone tells you to write a function that takes a number N and prints out 1..N in pseudo code(Which is basically what the pascal problem asks when they provide the formula for a row) and you can't even talk your way through a possible solution you're not going to be able to complete any interview process, no matter how gentle.

I personally would search for the mathematical formula and a text description that I could put on my second monitor as reference.

So you're complaining that you can't search for something that the interviewer is already providing?

I personally never work from verbal descriptions, I document the issue, and place it into a ticket system in which I work the tickets based on priority.

If you are this incapable of listening to a two or three sentence problem description, ask the interviewer to print it out for you and write "ticket #1" on it? I mean is your nitpick really "They told me the problem out loud instead of writing it down?"

This is even ignoring the fact that taking verbal problem descriptions is an incredibly useful skill as a software engineer. I mean I guess I could tell people to file another ticket and I could have the joy of e-mail tag as I have to send off clarifying questions further delaying the task.

"Candidates might get hung up on the gotcha part of it: the actual snip calculation. That's not something we care about, but that the candidates will likely think we care about. We should consider just giving them the formula (or letting them use a pre-defined "snip" method)."