Opera is also based on Blink.
610 karma · joined March 22, 2009
Opera is also based on Blink.
The first type requires the candidate to learn a lot about the existing code base. The second requires more mental work but is atypical of real work.
Implementing features sounds like a good idea. Perhaps create a small well defined system which is a simplification of the real world system and let the candidate implement some additional features.
I felt this was much better in that it was less stressful, yet allowed me to demonstrate both knowledge and design skills.
Another company did something similar but more thorough: They invite candidates for a full day of work where they try to solve a small problem. Then the code is reviewed and evaluated together. They also start the day with a 1-hour overview of their current architecture and you get to ask questions and talk about alternatives. I think this gives both sides a better chance of finding the right fit.
I realize this is not always reasonable.
It does put a lot of responsibility on employees: Don't leak internal data, but do express your opinion if something doesn't look right (and yes, perhaps even leak the offending documents if something illegal or clearly unethical is happening in the company)
3G is based on CDMA technology (wideband CDMA) and does require licensing fees. It doesn't really matter whether the chip manufacturer or the phone maker pays the fees. The end result is that non-Qualcomm chips make the product more expensive (and Qualcomm gets stronger anyway due to licensing fees).
There are a few objective reasons making it difficult to compete in the cellular business and a few Intel specific reasons:
- Intel's process and FABs are designed for high performance x86 chips. Not low power cellular chips. Given that the margins on x86 chips are also way higher, there was no incentive to change anything. So the cellular modems were produced using a power hungry process and were less competitive.
- At the time, Qualcomm was holding most essential patents required for implementing 3G (and probably now 4G). Licensing fees are enormous burden on anyone entering the market.
- Cellular technology undergoes tons of tests by operators, handset manufacturers, base station equipment manufacturers. It takes a lot of effort (and manpower) to execute all these tests and make the required modifications. It doesn't help that the reference platform is Qualcommm. So if you had made different a different tradeoff than Qualcomm, you may do better in some tests but will have to make fixes for other tests.
- Some problems are only seen in the field and only in certain places (due to quirky base station equipment, non standard deployment, etc.) Again, it takes a lot of effort to detect and fix those issues.
- Qualcomm (The big incumbent in this business) is huge: over 30,000 employees. No way you can compete if all you have is about a 1000-engineers in your cellular division.
By the way, the only successful cellular maker I'm aware of besides Qualcomm is MediaTek (Taiwan) which:
- Concentrates on the low end market.
- Ships complete solutions. You can find lots of different phones which are essentially a single MTK design with very few modifications.
Matlab will try to optimize and avoid a copy if the function does not modify the argument. Matlab is also (sometimes) smart enough so that A=f(A) will modify A in place instead of making a copy.
This is what I expect from a math oriented language. Maintain the illusion of referential transparency but optimize under the hood if possible.
Also Matlab has a reasonable JIT compiler. And a good debugger.
I no longer use Matlab but it is a very productive environment for scientific computing (simulations, exploration).
I think using 'make' with the -j parameter (# of parallel jobs) is more useful than using gnu 'parallel'. The reason is that if one of the job fails for some reason, you just re-run 'make' and only the required jobs are started instead of restarting the entire computation.
https://youglish.com/search/route/us
vs
There's also Kafka Streams which is suitable for many cases that do not warrant a full cluster with all the management and trouble required.
I.e., if you are generating reports, running aggregations over a large amount of data you definitely need some parallelism and Postgres isn't designed to handle these loads (certainly not petabytes). Even aggregating 100's of GB probably requires (or at least is more cost effective using) multiple machines.
Now Hadoop may not be a particularly efficient solution unless you need 100's of machines. But there is a limit to what a non-parallel single machine database can do. There are other solutions in-between.
And you really don't have to be twitter or google to handle significant amount of data these days. People are recording much more data in the hope of generating new insights and do need tools to process that data.
Personally, I much prefer this approach to using some limited template language to generate HTML.
So for numerical applications C++ may make more sense than Rust. Rust does have the advantage of being based on an LLVM backend. So perhaps different vendors can compete by writing more efficient backends that are applicable to both C++ and Rust (but you probably lose some information when skipping the compiler front end)
For example, since the standard library does not have a Matrix class suitable for numerical applications (or maybe it does today...) using multiple libraries each with its own Matrix class is difficult. Multiple libraries are needed since one library may not contain all numerical algorithms one may require for a given app.
This is not a problem for Google where I assume everyone is using internally written code -- but is a problem for most of us.
Play services can also instruct Google's servers to stop sending notifications when the device is in deep doze and re-open the connection when the device is active again -- thus saving power (messages are queued at Google's servers)
Stashes are for quick save and restore. Branches are way more powerful.
Go programs typically use RPC to communicate with plugins instead of loading dynamic libraries and calling functions in these libraries.
With complex Makefiles, at least you have the sources and can try to understand the logic. With Gradle, it's all tons of compiled java code.
Play services is responsible for connectivity with Google's servers which are used to distribute notifications to the device.
Play services is probably also responsible for backing up the App's data to Google servers (not sure about this one)
How difficult it is to use a Java library from Dart?