Absolutely I'm down to share.

We used off-shore teams (which I helped on-board) in South America (best devs) parts of Europe, India, and Vietnam. Anywhere from 20-90/hr.

Now we use in house and on shore remote ranging from 50-80/hr (80 current full time cap) and it is absolutely night and day different.

I could ramble about the differences and will when I'm not standing on a subway train, but if you have specific questions I'm happy to answer.

The biggest thing that everyone will likely tell you is that the offshore team will make a terrible architectural decision and then follow it for a while and make all of that resulting work completely useless and burn tons of time. They have a hard time knowing which questions they should ask for direction on and which ones are trivial.

US developers are often able to think like a user and deliver a more solid experience.

Whether that user is another developer or an actual end user or client, you are way more likely to get something usable and thoughtful from a US-based developer.

No particular questions. The general issue is that when I try look at it from an employer's perspective, I don't see a lot of advantage to hiring/contracting an individual US remote over off-shore outside of the potential language barrier. My only experience working with an off-shore team was a few months with some Bulgarians, and they seemed competent and professional.

It's possible I'm creating an issue out of nothing, and those with more experience in the matter have a more negative bias towards off-shore devs.

That's probably because you guys shouldn't' be leaving the architectural decisions up to the offshore team. The guidelines should be scoped and specific as to not to leave any leeway for misinterpretation.

Anyways, had this problem from a hackerrank contest that I could not figure out. I spent 3 hours and it is supposedly rated easy.



For example $5 would have 4 different ways.
(1,1,1,1,1)
(2,1,1,1)
(2,2,1)
(5)

Am I a dumbass?

I did a mock interview with a Google employee today where I got torn apart for doing some O(n+m) solution instead of O(logn). And then I saw this problem above; my confidence is at an all time low.

Apparently, I need more work with dynamic programming and divide and conquer. Whatever that is.

I think you can work up from 1.

So there's 1 way to make 1.

For each number N you go through all the bills B less than or equal to N and add the number of ways to make N-B.

So for 7. You add up the number of ways to make 6, 5, and 2.

Edit: my phone ate part of my response. But hopefully you get the idea. You might need to subtract duplicates though. Too lazy to think it through now.

Took me about 30 minutes. I wouldn't call it easy, but not really sure who the target audience is.

Keep in mind this only works for a currency whose next denomination is always at least 2x the previous denomination.

Here's a good one that a friend of mine that just took a new job was asked:

Using only rand(4)'s, solve for rand(9).

I was able to do it pretty easily with rand(3)'s, but the solution for rand(4)'s escapes me.

Anyone have a good solution?

Not sure I understand the question. What operations are you allowed in addition to rand(4)? Can you add them ? bit shift them?

I think you can do any other operation you want.

My solution for rand(3) is

if a solution that returns almost surely, and in practice will always return instantly, but theoretically might not return is ok, then just roll rand(4) twice, and then:
{1,1} = 1
{1,2} = 2
{1,3} = 3
{1,4} = 4
{2,1} = 5
{2,2} = 6
{2,3} = 7
{2,4} = 8
{3,1} = 9
anything else = roll again.

I don't think that will produce an even distribution?

daveT will surely recognize this as the making change problem from SICP:

https://mitpress.mit.edu/sicp/full-t...ml#%_sec_1.2.2

it will. each of those possibilities is equally likely. there are 9 of them. go ahead and try it.

Yep... I thought about it a bit and was coming back to retract.

lol

Yea that came out wrong.

US = "first world"

If you are building software for first-world users, having developers who share that culture will generally result in an easier time understanding and relating to the users they are supporting. Having someone in a completely different culture and adding communication difficulties will so often result in misunderstandings and missed requirements.

Yea, they shouldn't be making any architectural decisions, but even smaller decisions can have a large impact.

This is more like rand [-3, 5]

Regarding the hard on for recursion, it is a concept that is widely taught in CS undergrad classes and a unique, interesting (my view) concept. It is a favorite type of problem on tests in undergrad CS classes. Since tests are the way to measure achievement in undergrad CS courses, it is obviously the way to measure the achievement of an experienced developer.

Ymmv as to how much you actually will use it in your professional career. I believe it is fair to say that the current thinking when vetting people for their skill level is that if you don't know fundamental CS concepts, you can't write code. If you are a developer with ten years + experience and you can't apply recursion to solve a problem that you are given during the interview, you are a complete fraud and obviously have been getting by on kissing up to management and taking credit for completing assignments you didn't do. We'll be in touch.

Yes. Like in the question!

I think recursion is useful for testing because to really understand it you have to have a pretty good sense of how method execution works.

But it's not guaranteed to end.

There is no good solution for this because you would need a 4^n mod 9 = 0, and since 2^n mod 3 = 0 has no solution, 4^n mod 9 = 0 has no constant time and even distribution solution.

Here's a longer and more thorough write-up using 5 and 7, but same idea:

https://www.interviewcake.com/questi...e=weekly_email

even though it's theoretically not guaranteed, it is guaranteed in probability (with probability arbitrarily close to 1). so as a practical problem it's absolutely solvable.

same thing comes up if you ever find yourself in a group of 3 friends, and want to select one of you as the winner or odd man out, and have only a coin. friend 1 = HH, friend 2 = HT, friend 3 = TH, and TT = do over. you'll rarely have to do more than a single do over.

Yes, in a practical world, that doesn't matter, but this is all CS-y stuff, and I suppose it matters that you know this isn't O(n) and understand why that is true and understand why O(n) is impossible.

I discovered something that blew my mind the other day. Writing a "distinct val" using a pseudo loose index CTE is faster than writing "distinct val from my_table". Totally counter-intuitive because it seems like using a CTE is O(wtf?), but apparently, hashing and indexing makes using CTEs run orders of magnitude faster than the built-in "distinct".

I should have been better in explaining the problem. rand(3) returns 1, 2, or 3.

I know. Just pointing out something that many have never thought about or realized.

Thanks! Will take a look at that link.