That is the exact point the article is making. When you are junior you think that code style is the most important thing but it isn't. (Also it can be handled automatically as you say)
They might mean at customs? When you go through customs you have to get your bag and then recheck it but they do have a place to drop them off without having to go through security again so it's not that much of PITA.
All of this is why my primary use case for ebooks is actually borrowing them from the library. It's super convenient because I don't have to worry about returning it on time -- it'll just disappear from the my device! But if I'm going to buy a book I almost always want a physical copy. (I've bought digital of a few of my favs that I often re-read on vacation but I do own physical copies of them too)
You might currently be working a job that is 50 hours a week -- or 60! Also with the example of a single parent they often can't make room for yet another 10 hours of a work in a week because they need to spend time with their children/take them to activities/cook dinner etc. Manageable when you are working 40 hours a week but it quickly becomes unreasonable. To me a job that wants me to work for them before I have an actual job offer is a red flag. I don't even work for them yet and they don't respect my time. What's it going to be like when I do work for them?
Quitting your job or dropping some other responsibilities might he reasonable for some people who can live off of their parents money or their own savings, but for many people that means losing their home, their car, or even their children. Indigo945 isn't making excuses for them or himself; he's telling you that for them to make that 10 hours would cost them far more than the new job might give.
Also, if anyone should be able to make another 10 hours in their week to work in tech why not say Steve who works at $BigTechCo? Now I know we just asked Steve for another 10 hours, but lets go ask him for another 10. No, the circumstances shouldn't matter, he's making 6 figures after all. Let's ask him again. And again, And again. Oh, Steve quit? What a pauper.
The same can be said for requiring candidates to have a github or using a college degree as a filter. Not everyone has the luxury to take out 10's of thousand in debt and spend 4+ years of their life learning instead of earning.
So unless you advocate for completely blind interviews that do not rely on a resume and only take up 3 hours of someone's day, your point is moot.
It's a part of hiring someone to have them send in a resume and verify that they have the skills needed to do the job. I contest that it is not fair to disqualify candidates because they cannot meet arbitrary and unreasonable demands for their time. A phone interview is almost always reasonable. A 10 hour work sample due this week would often be unreasonable. It depends a lot on context and conanbatt discarded that.
> Indigo945 isn't making excuses for them or himself; he's telling you that for them to make that 10 hours would cost them far more than the new job might give.
Thats not a "people cant do 10 hours" its a "they dont want to" which is perfectly reasonable. The company that gives 10 horsu of work better be appealing.
But saying that take home assignments are bad because they take time people cant afford to give is complete bs.
I have trouble believing you aren't being facetious, trolling, or willfully ignorant. If you've spent any sort of time in this industry at all, you know that people apply to many places at once. Sure, one 10-hour assignment isn't much, but although you seem to live in a fantasy world where people only apply to (and receive) one "job application homework assignment" at a time, that's not actually how the real world works. Companies that tend to pull such nonsense also tend to have poor work cultures. I suppose it self-selects for people who don't have a family or out-of-work commitments, but maybe that's what they're going for.
I could put aside ten hours for an opportunity and not consider it an issue.
Applying ten places and getting 100 hours of homework knowing there's a good chance of ten businesses ghosting? I have plenty of empathy for people who have to make that choice.
There is no bending, there is an ask, and a response of "the ask is impossible to fulfill", which isn't. Its dishonest, but worse, its dumb because its obviously false and couterproductive.
Not spending 10 hours to decide where you might spend the next 20 thousand is plain penny wise, pound foolish. If a job ceteris paribus pays 5% more on a 100,000 income, and doing the work assignment gives you 50% changes of getting that 5%, its like getting 2,500 U$S per year for 10 hours. It pays for itself.
The kind of place that treats 10 hours this way is a kind of place that will treat you badly as employer. Same attitude will be applied in all aspects. The same very real considerations will be treated as dishonest excuses later on. Expect regular and long crunch and no control over when overtime.
Also, the assumption that forfeiting those 10h will make one financially worst off is likely wrong, especially in long term.
Lastly, we are not talking about 10h deciding, we are talking about 10h of a single take home assignment - there are more companies to talk with and decision making time is not in it.
Yeah, well except the complacent paupers part and dishonest part where very real considerations and decision making is casted as something shameful that makes you less capable. Likely serves to tilt the culture toward not speaking up about these openly.
Have you used flow at all in the past? If so what would you say the major differences are/how difficult was any process to convert over? I'm a huge fan of having the types defined just from a documentation perspective nevermind bug catching and debugging and all that. I feel relatively agnostic about the particular thing we use to do it so I'm curious as to what the differences are.
But yeah it really has improved my day to day immensely and I really feel the difference when I'm working in legacy portions of our apps that pre-date the flow adoption.
I have used both TypeScript (for multiple projects) and Flow (at Facebook). TypeScript is much more feature-rich and looser in strictness. In practice, this looseness has been preferable, as I've seen many of my colleagues fighting Flow's type system vs TypeScript (prior to FB). In theory, perhaps Flow's type system prevents more bugs, but I've sometimes seen it circumvented with hacks just to get past its strictness. TypeScript's ability to infer types seems much smarter than Flow's as well.
Besides that, TypeScript has much wider adoption and community support. Most issues I have with TypeScript I can find others who have had similar issues on the web, where as I can't say the same about Flow.
I would also like to know how many projects within Facebook, if any, use Typescript. I'd be interested in the growth rate as well (how many projects over time).
I have never used Flow beyond a basic hello world. The syntax is very similar. Some of the nomenclatures vary. All and all they will both accomplish 99% of the same thing - statically typing a dynamic language. Which gives you much more code confidence, `foobar is undefined` is very less likely. self-documenting code. (see: vs-code intellisense) And code maintenance scale abilities currently not possible with such a loose language like javascript.
So I would say if you're interested pick one and dive in.
And an extremely fast, open sourced, plugin enabled editor, vs-code ftw! I am a convert after being a longtime diehard vim user. (vs-code has the best vim binding emulation I have ever used in a free open sourced editor)
I've used Flow very heavily and TypeScript a reasonable amount. They're pretty similar really, but I'd recommend TypeScript for its better tooling and larger available set of type definitions.
Flow doesn't seem to be built with the (non-Facebook) developer experience in mind. It very frequently has breaking changes. The tooling is worse. There's no good official way to publish a package to npm with Flow type definitions included. Its alternative to DefinitelyTyped requires using their own CLI tool instead of copying DefinitelyTyped's simple npm-based strategy.
There a few things Flow does better. Functions internal to a file often don't need their parameters to be typed because Flow infers their types, but honestly I don't think that's a very killer feature. I often type them anyway just to be explicit. Flow does model type variance better (a Promise<{a:string,b:string}> can be cast to Promise<{a:string}>, but not vice versa, and you can't do the same with mutable arrays, etc.) but variance doesn't come up often and you can always use the any-type escape hatch in TypeScript to make it through those uncommon situations. I do hope TypeScript gets better about that though.
Flow isn't bad; a Flow codebase is still much better than an untyped Javascript codebase. But if you're starting a new project and have the choice, pick TypeScript.
Also errors in Flow are often very esoteric. The "smarter inference" sometimes made type errors appear in the callee rather than the caller (having an error on React's component type definition is not helpful). The wording isn't user-friendly if you're not familiar with typing theory.
Inference is not that much of a killer feature I feel: I don't want the type to be inferred based on how I use a variable, I want to check that I don't misuse the variable based on its type. Obviously there's use for inference too, but in the general case...
Also, if you're looking to introduce types to an extant Javascript project, there's a good chance you're already using babel. That used to be a (slight) point in flow's favor, but as of Babel 7, you can opt to have Babel transpile your TypeScript. Not that there's anything wrong with tsc. :)
Typescript's tooling is much better -- it's just a JS transpiler (and now you can use babel to do your transpiling if you prefer). Flow's daemon-style approach was a constant source of pain for me.
Flow operates very similarly: the recommended setup is to use it with Babel. Babel just strips out the type annotations from your code to make it into legal javascript. The Flow daemon executable was just to provide type checking. Before TypeScript also got similar Babel support, I considered it a strong point in Flow's favor that it was so easy to drop in if you already had a Babel setup going.
> The Flow daemon executable was just to provide type checking.
This is problematic. Now your webpack build is shelling out asynchronously to a second process. It makes it very hard to integrate type checking to a build system.
I've never connected Flow to webpack or my compile process like that. When I've used Flow or TypeScript with Babel, the build process and type checking were always two separate things. I treated type checking like unit tests: something I'd frequently re-check while working on code, but not something connected to the path of getting code running somewhere.
Not necessarily locally. On CI/staging/prod yeah definitely, but when I'm hacking around I'm fine with having type errors ("yeah yeah I know this is nullable, I don't care right now I just want to investigate this bug")
I absolutely want it locally, preferably inside my IDE where it's providing type hints, allowing navigation to type declarations, and alerting me immediately to typing issues live as I'm coding.
I don't really feel strongly about it, though sometimes Flow takes 10+ seconds to re-check a large project I work on after changes, and I wouldn't want building to have to wait on that. (I've never worked on a similarly-sized project in TypeScript, but I expect it's about the same situation.) I usually use a CI system (CircleCI) which sends me an email if any of my commits don't pass type checking or unit tests, and it flags any PRs on Github that fail too.
I've deployed flow extensively and the biggest difference is that flow is horribly buggy (lots of false negatives) while typescript is mature. In theory flow's type system is stronger but it's so unreliable that 99% of the time I'd rather use typescript.
48% I'm happy with that cause I'm pretty bad at actor names and such. There were a few that when I hovered over the tooltip I was like 'Oooooh yeah, I know that person' but I only clicked the checkbox if I knew without double checking.
Really? We have spike tickets all the time to go and explore a problem and see what edge cases we can find, explore possible solutions, and stuff like that. We usually scope spikes to a day or so. But we've had a couple where we were given almost a full week. The minimum I've spent was an afternoon and that was mostly because I actually found a lot of info a lot faster than expected.
Spike tickets are one of the funniest ways I’ve seen this handled. All it can really tell you is whether, in some short initial investigation, there is a known blocker, usually on the technical implementation side.
But the problems that make estimation useless are problems that only surface after detailed digging that takes time and cross-team communication not realistically possible in time-boxed spike tickets, involving happening onto things that were not known and could not be known within a short spike timeframe.
Spike tickets are just an Agile bureaucracy thing to paper over the fact that estimation is intrinsically problematic to some fundamental aspects of one-size-fits-all methodologies like Agile.
Essentially for a spike ticket to be helpful in the common case, you need a spike ticket that just says, “actually go and complete the whole task you’re trying to estimate and then come back and tell us how long it really took.”
agreed -- being able to verbally set timers is very valuable to me. Also I have Lifx bulbs in my living room and it is much easier to tell Alexa to turn them on/off/change brightness than it is to get out my phone. I only use the phone app for that when I want to set up some custom color thing (which is pretty rare tbh)
I actually see people using facetime in public all the time -- I think its one of those things if you aren't looking for it you won't notice. I've actually used google hangouts on my phone a few times -- recently I was in the airport w/o my computer on my Dad's birthday so we did a video call and other scenarios like that one.
Also, I lived abroad for a few years and I used video chat extensively with my parents and other friends back in the states. (TBF though a majority of the time it was on my laptop -- but sometimes I did use my phone!)
> Mostly teenagers yes, but them being the next generation of adults I doubt they'll just stop once they're into their twens. It'll just become the norm.
That one is potentially true although I'll say based off of our interns they seem to be pretty good about not being on their phones all the time when the situation calls for it. I think like most things its super individual because of my coworkers the person who is on their phone the most is actually a middle aged guy.
