> Maybe at some companies. Where I work, Engineering Managers and PMs are totally separate. So Engineers have much more representation.
Exactly!
843 karma · joined July 4, 2010
Exactly!
Can't say much for MS, but for the others the essential CS skills questions (should be...) relatively uniform for all experience levels. i.e. they are at graduate level.
Plus, Amazon count on these 'a lot' https://www.amazon.jobs/principles
Possibly more than the CS side of things in my experience.
There are some basic red flags raised:
> Our project manager would be displeased when tasks took longer than the estimate and would immediately assign one of the other team members to work with the original developer to hurry it along.
Shouldn't happen just at the whim of the PM. A sane environment would work by a developer asking for help first, and it actually sounds odd that you have capacity for a PM to throw someone to just 'hurry up' tasks
> Whenever there was any debate about refactoring the code, or backing out of a problematic feature, the new guys would argue against it, saying it was ‘ivory tower’, and not delivering features. The PM would veto the work...
Why does the PM have a veto? No technical lead or management with balls? PM's need to manage the features of a release and changes to the plan. Any PM who says features are set in stone isn't doing their job. A PM's role is to handle change and execute the plan. Sounds like weak management.
Programming languages take years to incubate and in five years time you never know what will happen.
Don't believe that a virtual machine based language is going to fly in true embedded environments other than toys though. I've got more faith in lightweight scripting languages for rapid development.
Once you've got to the point of getting a face to face interview - none at all, and then on day one of your job, your qualifications (even a PhD) in most reputable software shops become irrelevant to your colleagues.
In the longer term a masters can definitely help if you're involved with visa related processes.
If you obtained some specific domain expertise that is interesting to the employer in your thesis that can help. Then again, you don't necessarily need to do a masters to demonstrate such expertise. Creating and publishing applications, open source project involvement and the rest can be as valuable if not more so.
I’ve spent quite a few years coaching and dealing with developers with a heavy electronics background work in OO/C++ environments and I came to the conclusion that they would be more comfortable and competent in C. All smart people but the bells and whistles of C++ AND OOP just was confusing.
I’m surprised at some comments here claiming that OO is ‘friendlier to the programmer’, I would put money on the average developer being able to work their way around even the Linux kernel quicker than a comparably sized C++ code base with all it’s OO goodness.
What OOP was trying to solve back in the day was and still is a real problem but it annoys me how many additional problems ‘full blown’ OOP introduces.
“Cubicles even make people behave badly. Researchers at Cornell studied 229 employees at eight firms and found that those in cubicles were more prone than those in open-plan offices to have long, loud conversations—sometimes unrelated to work—with colleagues or on the phone.”
The key to making open offices work in a software development environment is fundamentally about having sufficiently low density, and having management giving a shit about basic conflicts.
There are enough failed and feeble mobile OS vendors out there (Symbian, RIM, Palm, Microsoft) to prove that doing what Android has done is hard.
The Android team under Rubin executed extraordinarily well with a tiny fraction of Google’s engineering resources.
In a way, you're almost looking at the interviewee as a teacher except they're obviously having to improvise on the subject at hand.
I'd suggest the best practice is to understand the structure of software you're interested in and write about it.
Android can't really look at the world like that, the platform is being used in wearables through to what will be console class devices.
Android must be able to work in the low-end, take project Svelte for example, as being important to get Android (back) to being usuable in 512MB devices.
Also typically most effective power management strategies run to idle then off, rather than keep power consumers alive at some nominal frequency.
> Overhead from repeatedly having to JIT the code? Cache it
Caching in memory is a limitation because of basic memory constraints, and caching to persistent storage (swap) is not a great option because of the relative speed of mobile storage and to a certain extent wear levelling effects on flash may also be a concern.
I argue that what gets lost in the fog when talking about JITs and virtual machines vs static / AOT based solutions is that VMs can be very performant when you can ignore startup time and when there is a single instance of a VM that you have to manage on a system.
Take an Android device and look at the number of activities resident at any one time, you'll have 10 maybe 20 plus activities present, each of which is an instance of a virtual machine spawned from Zygote. This makes memory footprint of the VM critical, because the penalty for restarting Activities is often pretty high.
sudo apt-get install haskell-platform
download and extract the tarball
cd awgn-cgrep-8af1beb
cabal cgrep.cabal
Unfortunately what stops me using it on a large codebase is that I can't exclude directories like .repo (not sure about .git).
No one is releasing ‘Biological life forms 2.0’ and worrying about whether penguins stop working.
The problem is that writing reusable software is hard, inheritance is a really easy way to introduce reusable code into your software but a bad abstraction or base class has viral effects.
Then again, it’s worth considering that the there is enough work to do to just get technical skills on the educational agenda. That requires getting attention, and it just might be that Dexter might be more relatable than a domain expert.
BTW, I think a truly ambitious initiative would be built on free software. With FOSS it's easier to explain how people who know how to code can use those skills to make changes to things that they use rather than just be consumers or specialists.
From a third party app point of view you can build your against Android API level X, or a corresponding ‘Google api’ release associated with the given API level. An app built against API level X will work seamlessly on the corresponding AOSP release.
So far, unless you’re interested in more tightly integrating into Google services, you don’t need to build your app against the Google api, but obviously Google are interested in app developers using their custom apis.
As far as the increasing integration of core applications into GMS is concerned, it is rather overblown to call the AOSP versions broken or buggy. AOSP remains the base platform for the hardware ecosystem to develop their reference designs, AOSP has to work and does work well.
The hardware domain is a big problem for rolling your own OS from scratch, the associated software stack to support a given piece of hardware is non-trivial. Even generic Linux is now being supplanted by Android variants in the embedded space especially if you’re interested in graphics or multimedia.
However, also consider that the most successful player in the Android space, Samsung, have pursued a strategy of lightly forking Android with their own features and customizations without breaking compatibility deliberately.
Context matters a lot for Microsoft.
Amongst older people, there are enough casualties of Microsoft's success around to warrant a default hatred for the company and it's values.
However, the saddest indictment is even at the height of their success many people didn't like or even hated using their products (take the parody of Windows/BG in South Park the movie in 1999 as an example if you like).
So I think Microsoft as a deserved reputation for considering the enjoyment of their products as a separate from the success of their business, at least in the mainstream. It's not to say that Microsoft don't do good products, but it's difficult to regain trust which is lost.
I agree that a lot of time has been wasted by Android vendors on differentiation for differentiations sake. It's easier to superficially fuck with the UI than actually create a useful features.
I'm a great believer in Loss Aversion (http://en.wikipedia.org/wiki/Loss_aversion) and Hotelling's law (http://en.wikipedia.org/wiki/Hotelling%27s_law) when it comes to device preferences.
These days I don't think many people are arguing that the iOS UI is significantly better than stock Android, Android has closed the gap or jumped beyond iOS depending on your personal preferences (Hotelling's law). Then consider how many people won't even consider iPhones because the screen size is too small (loss aversion).
The best office environments I worked in was in a different industry, where I worked part of the time in a laboratory because we were dealing with hazardous chemicals and specialist machinery. However, even as a junior employee I also had an office, only because the building itself was relatively under-occupied.
Stints in the lab varied, sometimes I was in their part of the day and at other times we were in their for several weeks pretty much full-time.
In my experience in the tech industry I've worked occasionally in full time lab conditions too for a stretch of a few weeks. Generally I've found these periods enjoyable as well, but after a long stint in "the lab" I've been glad to go back to a more isolated environment.
Given this experience I find weaknesses in all the arguments about whether dedicated offices or cubes or open-planned work environment are the best. Personal offices are obviously the least worse, cubes are a ghastly compromise in my opinion, and open plan has obvious problems.
If we're talking about ideal working environments, it would be one that allows focussed rather than forced collaboration. Labs allow for this but are rarely thought about because of the phyical constraints of most office spaces. *Oh, and it requires imagination and effort from management too.