Having worked at both places, Amazon's number might be true, but its totally different. GB is pushing everything out 3 times a day with minimal testing. Amazon is letting each group push their own microservices out at their own schedule, after they feel its sufficiently tested them. And there's an integration environment they can push to first if they have a lot of dependencies. Worlds different.
That actually is a great description of Facebook. If you can get one other engineer to approve a code review, you can push absolutely anything to master and have it deployed with the multiple times daily automatic deployment.
This isn't the bigger problem, as having both partners on the pill reduces the chance of accident. The bigger problem is that unlike a condom, the pill does not reduce the chance of STDs. That's why the male birth control pill was never pursued as much, men already have a high 90% success contraception technique that also prevents disease spreading. And it comes without side effects from hormone therapy.
Having all 3 (condom, male pill, female pill) would be even stronger prevention, but I'm not sure I'd risk the possible side effects to get it from.01% to.0001%.
And my bet is they take that 15% even if not related to coding. For example if I go to the bootcamp, can't find a coding job, but 2 years later luck into a sales job that pays 40K a year, I'm paying that 15%.
Insurance isn't worth the cost, if you can afford to cover the loss yourself. If it wasn't a negative expected value, there'd be no profit in providing it. It makes sense only when in the case the insurance is needed you couldn't afford the cost. So homeowners insurance tends to be good, insurance on your phone tends to be bad.
There's a minimum, but that minimum bar will be much lower than the average game's. And going much above the minimum won't help. A definite change, and one that would make the idea of a "gaming machine" pointless. If it works well and catches on, it would change the PC and parts market.
Tell that to Boston and Seattle, where boring machines had major problems resulting in projects being years late and huge overages. Tunnels are not impossible, but they are difficult, expensive, and risky.
No, it absolutely wouldn't. Because you'd still have to wait for the result of every possibly branching instruction in order to execute the next. Having a billion cores per app won't fix that.
Inifinite cores wouldn't make speculative execution not needed. Speculative execution exists because you're trying to do things sequentially. Putting another core in there won't speed it up in any fashion- to avoid speculation you have to wait until the branch is determined. You could remove speculative execution and the optimization it provides, but yo'll end up with a FAR slower processor as your core will be idle from the beginning of a branch statement until its done- putting in a lot of noops into the pipeline. The deeper the pipeline in the architecture, the worse it will be.
Do you want to go back to the computer you used in the early 90s? Because that's what you're going to get if you remove it entirely.As for the idea of not letting different apps share the same core- so you want to get rid of mutltasking? Because you have very few cores compared to the number of processes running. Sharing cores is basically how all multitasking works.
No, I'm looking for people who can put out decent quality code despite time restriction- in other words people who are productive in the real world. Which seems to exclude you.
No shop ever has enough time to get it completely right. Especially not startups. Welcome to the real world- perfect is the enemy of the good. It doesn't matter if you can write something that's so beautiful it brings tears to the eye if that takes 10x the time to get it done well enough. The well enough is better.
Look up what you want. When I'm in an interview I don't care if you get the syntax of the actual html call right, or if you swap the parameters to fread. Hell, I can't remember what the order in fread is. What I'm looking for is your ability to think through the problem and find a solution, and ability to find alternate solutions or problems with an initial solution.
Doctors are a completely different territory- there's standards bodies who have certified that this person has the skills. Furthermore, if I was getting major surgery on a non-emergency basis, I damn well would spend time researching success rates and reading their history with the state medical board. I've known people who almost got unnecessary surgery before they went and got a second opinion (which they then confirmed with a 3rd opinion, to tie break the first two).
Who said anything about reverse this string? The last question I gave to someone for an on site interview was to give him a computer and ask him to write as much as possible of a minesweeper clone on Android (the position was for a mid level Android position). I didn't even really expect him to finish, I wanted to see how far he got and how he modeled the data/architected the solution. Particularly if he could get the open algorithm correct and reasonably efficient (the part where when you click on a "0" square all surrounding squares reveal themself and propagate).
Your expectations are orders of magnitude too high. People lie. Not everyone, but I've had plenty of people try to get jobs that are way too high level for them, many without even more than the absolute basics of programming. A couple without even that (they read a few tutorials and signed up online because they wanted to work in tech). You're too trusting and expect too much honesty from the random person. Even if 90% of people are honest, that last 10% will utterly fuck you. A bad hire will do more harm to a company than missing a good one.
As an aside- I have no problem with an "I don't know" if its something I think they're capable of learning and the position gives them the time to do so. The goal of a technical interview isn't to give trick questions, and unless you really need a subject matter expert it isn't to make sure they know everything on a subject, its to assess skill level overall and ability to learn what's needed.
I don't take the basics for granted because over 18 years in this profession I've found that to be wrong way too often. I've interviewed plenty of people who would fail reverse a string (which is not a test I actually give). As for that being what their production code might look like- not really. You're always under time constraints. While I expect what's been done over the course of a day or two to look better than over the course of a few hours, that isn't what we're talking about here- they had unlimited time to massage it, get reviews from peers (which I've been asked to do many times for other people's interview code, and which isn't something you can do in real work), get many rounds of feedback. It isn't realistic to what you'd be writing under normal deadlines at a job.
BEcause you launched the app into a specific activity. Back doesn't mean go to home. It means finish() the current Activity and let the previous thing on the stack come up. Which if you launched it directly into the message activity is back to the OS or previous app.
Think of it this way- if you hit the notification for a message, read it, and hit back, do you expect to go to the list of messages? No you expect it to go back to where you were previously, usually another app. This is what's happening. If you changed this, then notifications and similar flows would feel broken.
ANd they bullshit enough to get in. Or get trained in it by the guy they hired.
Nope, have them write it in front of me. Its the only way to be reasonable sure. Plus, as I mentioned before, then I see code they write in the moment, not code they've polished over the course of weeks/months to be used as an example.
Except they're picking the code, so of course they studied their specific example. Instead, I'll just have them write it in front of me and then I don't have to worry.
I'll also have some idea of what style they write in on what timeframe. I don't want to see code you've spent months or years working on and polishing, I want to see code you write under a reasonable deadline, because that's what you'll actually be checking in.
No, there aren't any pros for gestures. They're less discoverable, require more effort, and they don't work in fullscreen apps like you claim- they are in fact far more likely to interfere in apps at any size because swiping is a very common operation. This is just a horrible idea from start to finish.
No, because I don't know that you actually wrote the examples of you work. I can't even count the number of times on freelancing sites I was asked to create them (and a few times outside of that- graduating college I was asked by a lot of people to do it for them). If you don't do it in front of me, I can't trust that you can actually do it.
Now a roomfull of people at once- yeah that's a dumpseter fire get the fuck out. This type of thing should be done one on one.
Slashdot Mirror
Having worked at both places, Amazon's number might be true, but its totally different. GB is pushing everything out 3 times a day with minimal testing. Amazon is letting each group push their own microservices out at their own schedule, after they feel its sufficiently tested them. And there's an integration environment they can push to first if they have a lot of dependencies. Worlds different.
That actually is a great description of Facebook. If you can get one other engineer to approve a code review, you can push absolutely anything to master and have it deployed with the multiple times daily automatic deployment.
This isn't the bigger problem, as having both partners on the pill reduces the chance of accident. The bigger problem is that unlike a condom, the pill does not reduce the chance of STDs. That's why the male birth control pill was never pursued as much, men already have a high 90% success contraception technique that also prevents disease spreading. And it comes without side effects from hormone therapy.
Having all 3 (condom, male pill, female pill) would be even stronger prevention, but I'm not sure I'd risk the possible side effects to get it from .01% to .0001%.
And my bet is they take that 15% even if not related to coding. For example if I go to the bootcamp, can't find a coding job, but 2 years later luck into a sales job that pays 40K a year, I'm paying that 15%.
Facebook is worse than that. In the summer their number swell by almost 50% due to interns.
Insurance isn't worth the cost, if you can afford to cover the loss yourself. If it wasn't a negative expected value, there'd be no profit in providing it. It makes sense only when in the case the insurance is needed you couldn't afford the cost. So homeowners insurance tends to be good, insurance on your phone tends to be bad.
In many states, yes.
There's a minimum, but that minimum bar will be much lower than the average game's. And going much above the minimum won't help. A definite change, and one that would make the idea of a "gaming machine" pointless. If it works well and catches on, it would change the PC and parts market.
Tell that to Boston and Seattle, where boring machines had major problems resulting in projects being years late and huge overages. Tunnels are not impossible, but they are difficult, expensive, and risky.
No, it absolutely wouldn't. Because you'd still have to wait for the result of every possibly branching instruction in order to execute the next. Having a billion cores per app won't fix that.
Once again- who the fuck sai anything about string reversal? Keep batting at strawmen though
Inifinite cores wouldn't make speculative execution not needed. Speculative execution exists because you're trying to do things sequentially. Putting another core in there won't speed it up in any fashion- to avoid speculation you have to wait until the branch is determined. You could remove speculative execution and the optimization it provides, but yo'll end up with a FAR slower processor as your core will be idle from the beginning of a branch statement until its done- putting in a lot of noops into the pipeline. The deeper the pipeline in the architecture, the worse it will be.
Do you want to go back to the computer you used in the early 90s? Because that's what you're going to get if you remove it entirely.As for the idea of not letting different apps share the same core- so you want to get rid of mutltasking? Because you have very few cores compared to the number of processes running. Sharing cores is basically how all multitasking works.
No, I'm looking for people who can put out decent quality code despite time restriction- in other words people who are productive in the real world. Which seems to exclude you.
No shop ever has enough time to get it completely right. Especially not startups. Welcome to the real world- perfect is the enemy of the good. It doesn't matter if you can write something that's so beautiful it brings tears to the eye if that takes 10x the time to get it done well enough. The well enough is better.
Look up what you want. When I'm in an interview I don't care if you get the syntax of the actual html call right, or if you swap the parameters to fread. Hell, I can't remember what the order in fread is. What I'm looking for is your ability to think through the problem and find a solution, and ability to find alternate solutions or problems with an initial solution.
Doctors are a completely different territory- there's standards bodies who have certified that this person has the skills. Furthermore, if I was getting major surgery on a non-emergency basis, I damn well would spend time researching success rates and reading their history with the state medical board. I've known people who almost got unnecessary surgery before they went and got a second opinion (which they then confirmed with a 3rd opinion, to tie break the first two).
Who said anything about reverse this string? The last question I gave to someone for an on site interview was to give him a computer and ask him to write as much as possible of a minesweeper clone on Android (the position was for a mid level Android position). I didn't even really expect him to finish, I wanted to see how far he got and how he modeled the data/architected the solution. Particularly if he could get the open algorithm correct and reasonably efficient (the part where when you click on a "0" square all surrounding squares reveal themself and propagate).
Your expectations are orders of magnitude too high. People lie. Not everyone, but I've had plenty of people try to get jobs that are way too high level for them, many without even more than the absolute basics of programming. A couple without even that (they read a few tutorials and signed up online because they wanted to work in tech). You're too trusting and expect too much honesty from the random person. Even if 90% of people are honest, that last 10% will utterly fuck you. A bad hire will do more harm to a company than missing a good one.
As an aside- I have no problem with an "I don't know" if its something I think they're capable of learning and the position gives them the time to do so. The goal of a technical interview isn't to give trick questions, and unless you really need a subject matter expert it isn't to make sure they know everything on a subject, its to assess skill level overall and ability to learn what's needed.
I don't take the basics for granted because over 18 years in this profession I've found that to be wrong way too often. I've interviewed plenty of people who would fail reverse a string (which is not a test I actually give). As for that being what their production code might look like- not really. You're always under time constraints. While I expect what's been done over the course of a day or two to look better than over the course of a few hours, that isn't what we're talking about here- they had unlimited time to massage it, get reviews from peers (which I've been asked to do many times for other people's interview code, and which isn't something you can do in real work), get many rounds of feedback. It isn't realistic to what you'd be writing under normal deadlines at a job.
BEcause you launched the app into a specific activity. Back doesn't mean go to home. It means finish() the current Activity and let the previous thing on the stack come up. Which if you launched it directly into the message activity is back to the OS or previous app.
Think of it this way- if you hit the notification for a message, read it, and hit back, do you expect to go to the list of messages? No you expect it to go back to where you were previously, usually another app. This is what's happening. If you changed this, then notifications and similar flows would feel broken.
ANd they bullshit enough to get in. Or get trained in it by the guy they hired.
Nope, have them write it in front of me. Its the only way to be reasonable sure. Plus, as I mentioned before, then I see code they write in the moment, not code they've polished over the course of weeks/months to be used as an example.
Except they're picking the code, so of course they studied their specific example. Instead, I'll just have them write it in front of me and then I don't have to worry.
I'll also have some idea of what style they write in on what timeframe. I don't want to see code you've spent months or years working on and polishing, I want to see code you write under a reasonable deadline, because that's what you'll actually be checking in.
No, there aren't any pros for gestures. They're less discoverable, require more effort, and they don't work in fullscreen apps like you claim- they are in fact far more likely to interfere in apps at any size because swiping is a very common operation. This is just a horrible idea from start to finish.
No, because I don't know that you actually wrote the examples of you work. I can't even count the number of times on freelancing sites I was asked to create them (and a few times outside of that- graduating college I was asked by a lot of people to do it for them). If you don't do it in front of me, I can't trust that you can actually do it.
Now a roomfull of people at once- yeah that's a dumpseter fire get the fuck out. This type of thing should be done one on one.
That's great- except they went to virtual buttons a long time ago. THere's no advantage in a swipe over an onscreen virtual button.