Senior Software Engineer Role Test - What to expect?

BrokenArrows

I'm applying for senior software engineer role at the moment and they have sent me a test to do in my own time. Its a blind test so once i press start im given the details and i have 2 hours to submit the resulting visual studio solution.

Ive never done something like this before because ive been working for the same company for years and have gotten internal promotions to the senior engineer position.

Any idea what i should expect?

BrokenArrows

Did the test.
Bit of an odd one. It was a question to create an algorithm to calculate a value.
I won't go into detail as the test says not to publish it.

However it was basically a maths question. Nothing to do with programming. I obviously failed to get the algorithm right.

a fat guy

Sounds like they were looking for a computer scientist rather than a senior software dev.

tobsey

Try www.codility.com. They offer developer testing as a service to prospective employers. They do training excercises and regular challenges for developers to practice. It'll get you used to doing these types of tests anyway.

jester77

We do this with applicants, we open up a repo for them and give them 2 or 3 hours to complete a challenge. It's not about completing the challenge, it's to see how you approach it and what your design is.

Afterwards we look at the commit history and the end results and evaluate it. If we like what we see, we will have a phone interview with a bit of a Q & A session regarding the implementation.

If that goes well, then we fly in the candidate for an onsite interview.

matrim

jester77 wrote: »

We do this with applicants, we open up a repo for them and give them 2 or 3 hours to complete a challenge. It's not about completing the challenge, it's to see how you approach it and what your design is.

Afterwards we look at the commit history and the end results and evaluate it. If we like what we see, we will have a phone interview with a bit of a Q & A session regarding the implementation.

If that goes well, then we fly in the candidate for an onsite interview.

If it's something that only takes 3 hours won't the commit history be one commit for a lot of people

jester77

matrim wrote: »

If it's something that only takes 3 hours won't the commit history be one commit for a lot of people

I would hope not. You should be making small commits and committing often. Just looked at the last 5 candidates - 31, 12, 26, 19, 11 commits.

matrim

jester77 wrote: »

I would hope not. You should be making small commits and committing often. Just looked at the last 5 candidates - 31, 12, 26, 19, 11 commits.

For 3 hours work you might get anywhere between 1 or 2 commits from me. Especially for a new program / feature where it does nothing at the start. There is no need to be committing every tiny change because you just end up having to merge in loads of tiny changes from everyone else

BrokenArrows

a fat guy wrote: »

Sounds like they were looking for a computer scientist rather than a senior software dev.

Yes which is a bit odd as they are a company who writes hotel industry phone/tablet apps and backend web api's.

BrokenArrows

jester77 wrote: »

We do this with applicants, we open up a repo for them and give them 2 or 3 hours to complete a challenge. It's not about completing the challenge, it's to see how you approach it and what your design is.

Afterwards we look at the commit history and the end results and evaluate it. If we like what we see, we will have a phone interview with a bit of a Q & A session regarding the implementation.

If that goes well, then we fly in the candidate for an onsite interview.

That would make sense if there was any coding involved.
This question is basically a straight maths question. No complex coding required.

punk_one82

matrim wrote: »

For 3 hours work you might get anywhere between 1 or 2 commits from me. Especially for a new program / feature where it does nothing at the start. There is no need to be committing every tiny change because you just end up having to merge in loads of tiny changes from everyone else

I'd definitely see something like 31 commits in 3 hours to be complete overkill, but it does suggest that the person is breaking the problem down into tiny parts and probably working to a TDD philosophy, writing failing tests, making them pass and then checking in the code that made the test pass and moving on to the next piece.

So yeah, I think it's complete overkill but probably a good sign. I can't imagine they'd always be checking in that frequently over the course of 3 hours.

BrokenArrows

punk_one82 wrote: »

I'd definitely see something like 31 commits in 3 hours to be complete overkill, but it does suggest that the person is breaking the problem down into tiny parts and probably working to a TDD philosophy, writing failing tests, making them pass and then checking in the code that made the test pass and moving on to the next piece.

So yeah, I think it's complete overkill but probably a good sign. I can't imagine they'd always be checking in that frequently over the course of 3 hours.

I suppose you couldn't tell if its a good indication unless you actually looked at the checkins.

punk_one82

BrokenArrows wrote: »

I suppose you couldn't tell if its a good indication unless you actually looked at the checkins.

Yeah I'm not suggesting that you can tell he's good purely because he made a lot of commits, just that it's potentially a good indication of a well thought out, pragmatic approach.

All the commits may have still been horse****

Giblet

Number of a commits is a metric of ****-all when it comes to code quality. Commit granularity should be small enough to do a code review on (although I could argue an entire branch should be reviewed at once and the branch reflects one feature), but large enough so we aren't nickle and diming every line of code.