Hey guys, so I'm not a software developer, more of a math/signal processing type, but I applied to a job that will require some C++ coding. They sent me a 2 hour online coding test thing.

Any idea what I can expect, or what reading/practicing I can do ahead of time to better be prepared? Consider any differences between math/algorithms and more standard software development that you might think of.

What site did they send you to? Lots of them, like hacker rank, have lots of other problems you can practice on.

Oh sweet thanks, yea it's hacker rank, didn't even realize this was a full blown site with practice problems, I'll def do some of those.

This is probably a stupid question but... I got an email with a start challenge button saying that I have 120 mins once I click start. I would assume though that if I create an account with the same email the invite was sent to, it won't trigger that or anything, right? I can sign up, do other problems, and just avoid the start challenge button until I'm ready?

The guy at the company I'm applying to said "signing in starts the clock" which had me worried. Is he just being imprecise with his speech there?

Why not use a different email for the practice problems?

I'm not sure if I am understanding this correctly. If you want to practice hackerrank problems and be familiar with the platform you can do that by going directly to hackerrank.com. It won't trigger the start time for anything.

Once you are ready to take the test, use the link in the email and you are good to go.

Yup I just went this route just to be super safe. Thanks!

Cool yea good to know, and this is what I guessed. The guy just worded his email weirdly. I dug up an alt email just in case though so nbd. Thanks though!

Sorry Saw, missed earlier, but I had one recently and you actually end up having to click start like 3 diff times, and they even offered an option to take a practice test first to get familiar with the platform. I would guess its similar

Thanks! Yes I remember that conversation Been ages since been here kinda missed it will try jump in a few more threads!

I believe you were banned from OOT at a point, consider it lifted

Does anyone have any suggestions for the below scenario:

My team has two GIT branches:

'main' branch which services our production environment
'update_1' branch which was forked out of main branch
The idea is that 'main' is our current production branch. We only allow small bug fixes to be added to this branch to resolve critical production issues. 'update_1' branch is the next release we are working on. This branch has larger feature items that take more time to develop and stabilize. Once development is complete in 'update_1', we will push this branch to production, and then fork a new 'update_2' branch out of 'update_1' branch to start working on the next update. 'main' branch will no longer be used once 'update_1' branch is pushed to production in its place.

Due to this branching model, any fix that is committed into 'main' branch, must also be integrated into 'update_1' branch, so we do not lose the fix when 'update_1' branch is pushed to production. Similarly, we need to integrate all fixes from 'main' and 'update_1' branch into 'update_2' branch (once it is created), so we do not lose any of our in-production fixes once 'update_2' branch ships to production.

Currently, this is a manual process. We have our developers cherry-pick their changes into the needed branches. This has a lot of overhead and often times delays while we wait for the dev to integrate their fix into the needed branch. I am looking to automate this processes.

Is there any scripts or automation that can resolve this issue? I need to integrate all commits that are in branch 'main' into branch 'update_1'. If there is a marge conflict, we would need to flag this commit for developer review.

Thanks!

Why don't you create update_2 from main (after update_1 is merged in) instead of creating _2 from _1 and additionally bringing in commits from main?

If the intention is to bring all commits from branch X into branch Y, why cherry-pick them individually instead of using merge?

fwiw where I work we have a similar-ish workflow, but I think we do less cherry-picking than your workflow implies. Ours is like...

- master branch, never replaced, development takes place here
- create new branches for release, cherry-pick individual commits from master that we want to include in releases
- no need to merge from release -> master because the stuff in release was already taken from master

Branching strategies are the stuff of wars as epic as vim vs emacs but have the added bonus of being between co-workers where other people ace actually impacted by the decision. I long ago resolved to never be part of the decision as long as I trusted the people making it.

Here's our current approach:

- master is prod. If it's on master it's running in production or will soon be released to production (hours not days/weeks)
- dev is in progress. If it's on dev it's running or will soon run in our dev environment.
- feature development is done individually by branching from prod. To test it's merged into dev. Anyone at any point can merge prod code into dev (which happens every time someone wants to test their feature).
- occasionally dev is reset to master to remove cruft that was tested but never released.

It works pretty well.

Edit: One good feature of this approach is there's never any cherry picking or confusion about what is on prod. You still get some confusion/manual work reapplying unreleased features to dev after a reset. But that's a place where screw ups aren't costly. And each developer is automatically the one that deals with merge conflicts on their feature.

What goofy said, but also, don't do this.

Branch off main for your development branch, then merge dev branch back into main to release. Rinse and repeat.

Or, just keep a permanent dev branch and merge it into main and release from there.

I know this isn't helpful but personally I've embraced the "release early and often" philosophy and I've encouraged employers to also. We push to our main branch regularly. It's continuously deployed to our staging environment. At any point we can deploy main to production, in practice we do it about once a week. (At my last job, you deployed a fix or feature as soon as it was done, so I might deploy 3 times a day)

Ive done what rusty described before and I like it too. I think it's typically better for smaller teams (bit less overhead from what I described) but not as good for larger teams (there's an all or nothing around releases). If someone merges a feature to dev that's broken or needs long testing then it can block the whole release for everyone.

Thoughts on gitflow? It's what we currently use, but a quick googling shows it has some haters.

Why do you care what others think if you're already using it? What is it missing that you need?

I care if there are valid criticisms of the method.

I care if there is something better out there.

I care if there are flaws in it that I haven't realized yet myself.

Here's our git workflow that's worked pretty well. I think it's mostly standard?

master - always reflects what's in production, only updated after latest release or bugfix goes live with no issues. Lead dev or DevOps team will own this.

release/XXv12 - working branch for next release - anything that will definitely go into the release goes here. Spawned off of master or release XXv11. Lead dev will own this.

feature/feature_name - features to work on for future releases, or stretch goals for next release. Typically one dev will own this and make sure it stays up to date with the next release branch (or deal with all kinds of merge conflicts if they don't).

dev/[your name]-[feature name or release name] - individual dev branches for devs working on features or upcoming releases. Merged frequently back into feature or release branch, also the responsibility of devs to keep up-to-date with the next release branch.

Not sure how much we use bugfix/XXX as we tend to just release every few weeks.

Oh yeah - and no rebasing under penalty of gulag.

Im sure a lot of you saw this already, but this is pretty cool:

http://stackoverflow.blog/2017/02/Wh...ages-Weekends/

XSLT? WTF? I love XSLT - haven't seen that on a job req for a decade. Where are all the XSLT jobs?

Thanks PJo, that's interesting. C/C++ being more popular on weekends is the opposite of what I would have expected. Coupled with the increase in "pointers" on weekends, I wonder if that's indicative of people learning them as a first language to get into programming?

I wonder what the overlap is between the posters during the week and those who are posting on the weekends?

There are a lot of tags there relating to learning noobs (recursion, algorithm, class) but there's also "assembly", so the C (especially) and C++ might relate to people doing low level programming. Why people are doing low level programming on weekends is a mystery to me, but there we are.

Someone speculated it was students studying on the weekends.

I guess a lot of courses still involve assembly for some ridiculous reason.