Shakepay | Senior/Staff Full Stack, Senior/Staff Platform DX | Full-time | Canada (remote) | https://shakepay.com/

Hey folks, I am a long-time lurker and a first-time poster (in this thread). I'm Michael - Head of Engineering at Shakepay, a FinTech located in Canada (with offices in Montreal and Toronto). We're looking to hire senior/staff folks to help us build and launch new financial products at the intersection of Crypto and traditional finance! We've raised over $44M and continue growing and scaling.

Take a peek at our openings: https://shakepay.com/careers#openings

Hi Michael, stoked to see you here!

I am a fullstack developer based in Downtown Toronto. As a longtime Shaker (fluxxmojo), I really appreciate how you're making crypto more accessible to Canadians. I wanted to ask if theres room on the team for a junior/entry level? I'm also a big believer in the "little bit of slope makes up for a lot of y-intercept" philosophy, and have always dreamed of joining the team at Shakepay. I’m more than willing to fill any gaps and learn whatever is required.

Hey, looked at careers, but didn't see anything that fits well.

If you're still looking at expanding eng leadership I'd be interested in chatting.

Hence the followup - I will link to it in the original article.

netvibes.com open in an tab aggregating the web and letting me know when more to read.

How much of the failure is related to process or project management vs. the tech teams's skills?

Bingo! I have seen the smartest engineers (Princeton PhD in one case) rot in bad environments and mediocre engineers provide solid contributions in strong, engineering focused environments. I have rarely come across an engineer that doesn't want to build great products. If you want to suck the energy and enthusiasm out of team, add in weekly 120min planning meetings, required daily progress reports, and 4-5 product pivots.

I wouldn't be able to make a definitive judgement on that. But what I can say is that at my previous place of employment, we had a number of projects that never saw the light of day because the other organization couldn't meet their milestones. We were in direct contact with their dev team.

Oh, for sure - worked in capital markets and getting any integration between the different teams was an unpleasant affair. However, it usually wasn't due to a lack of talent, but due to politics or personality - somebody who likes to say "no" a bunch, or refuses to allow some other approach. Most of the devs were grumpy, but liked the steady pay and stuck around. Probably the root of the problem - if retention became an issue, perhaps things would change?

But what made you think the primary reason for their failures is the lack of good engineers?

I can't speak for management, but our team would inform their team on what was broken, and it would not get resolved in a timely fashion.

We would get contacted by the client to resolve an issue on our end, and after some debugging we would consistently discover it was broken because of the other company. They couldn't produce code that worked.

This could have been a management problem. For example maybe they simply did not care enough about the project to allocate the necessary dev resources. But it also could have been resolved on the dev side if they did a better job of testing their code that they claimed was complete.

Edit: I guess the most direct answer would be, since it was a problem that I could have resolved with tech, I didn't see a reason why they couldn't resolve it with tech.

"I guess the most direct answer would be, since it was a problem that I could have resolved with tech, I didn't see a reason why they couldn't resolve it with tech."

That really captures how engineers think. I think I often think the same way but my gut feeling is that there might be a fallacy in that way of thinking. I can't think of it right now but your statement does give me a bit to think about. I'm not saying you're wrong. In fact, I think the same way and that worries me :-)

There can be a lot more that's going on than just they are bad programmers:

- They are solving a fundamentally hard problem: it's a problem that at first glance looks easy, but turns out to be really really hard (for example: http://en.wikipedia.org/wiki/Travelling_salesman_problem)

- They are under-resourced and/or over-committed: they know how to fix your problem, they just don't have time to do it.

- Your not paying them enough to make it worth fixing: similar to the above, but in this case you simply don't represent enough revenue to make the doing the fix cost effective. Especially if it's a problem only you have.

- They have architecture constraints that make it hard to fix the problem: a bad/simple/incorrect design may make fixing the problem very hard

- They have legacy code which was poorly written or simply coded very fast and is now brittle and difficult to fix.

- They have internal political problems which are preventing them from fixing the problem.

I'm sure there are more that others here on HN have seen.

The worse case I saw of this was with a contractor who underestimated how hard the problem was, under-resourced the project and the resources that where on the project where not very good engineers. That project crashed and burned so hard there were lawsuits.

I was tired of last.fm providing me the same old recommendations, so I came up with findmusicfor.me. It's rough - only a few hours of coding involved, but thought I'd see what people think of it and ways to improve.

If you find another position, take it. Don't try to use quitting as leverage to make things happen - even if you stay on, your actions will always be there, lurking in the background.

Yeah, that's the next stop. :) Thanks.