Amazon | Software Development Engineer | Seattle | ONSITE

As Alexa Shopping we strive to enable shopping in everyday life. We allow customers to instantly order whatever they need, by simply interacting with their Smart Devices such as Echo or Fire TV. Our Services allow you to shop, no matter where you are or what you are doing, you can go from 'I want that' to 'that's on the way' in a matter of seconds. We are seeking the industry's best to help us invent new ways to interact, search and shop. Join us, and you'll be taking part in changing the future of everyday life. You will have an impact on Amazon's new devices and the way shopping is done in the area of IoT. And finally you will have the satisfaction of being able to look back and say you were a key contributor to something special from its earliest stages. You'll have the freedom (and encouragement) to experiment, improve, invent, and innovate on behalf of our customers.

Ideal candidate will have at least a bachelor’s Degree in Computer Science or related field with 4+ years of professional experience in software development. Knowledge of Computer Science fundamentals in object-oriented design, data structures, algorithm design, problem solving and complexity analysis is required along with proficiency in, at least, one modern programming language such as Java, C, C++ or Objective C.

Preferred Qualifications include familiarity with machine learning, experience building large-scale online services, ability to comfortably work in a fast-paced and ambiguous environment and knowledge of professional software engineering practices.

Send resume to: saili@amazon.com

The winning team did a writeup on the event and how one of the sections they used automation to solve. I think it was a Vigenère cipher.

But in this case, another student is taking your SAT exam after you've handed it in and filling in blank answers with wrong answers.

Further, that student has no ID and misspelled your name, but some how you still don't get to go to college.

Google just keeps creeping deeper into the shade ...

No question that somebody is cheating or that the teacher should do something. Just saying, the algorithm is punitive for a reason.

From that list, workers with disabilities are also exempt?

That's an exemption from the federal minimum wage (the "MW" next to it). It seems to be designed to encourage employers to hire disabled workers they might not otherwise employ, though I don't know whether it has positive effects in practice. It does have some provisions aimed at reducing abuse, such as requiring employers to first come up with an objective test of disability relative to the job in question (e.g. this person performs at 80% of the capacity of a typical non-disabled worker), then to determine the prevailing wage for non-disabled workers in similar jobs, and then to pay them no less than e.g. 0.8 x prevailing_wage, which can as a special exception to the minimum wage drop below the usual minimum-wage level.

PDF: http://www.dol.gov/whd/regs/compliance/whdfs39.pdf

Note that a bunch of the things on that list are exempt from that particular law because they are regulated specifically by a different law.

HR regulations, always fun!

The iterations are listed as 12000. This value is supposed to double every two years and is around 128k I believe currently.

This is probably to try to offset Moore's law, by keeping the hash cracking difficulty in line with technology progrss. But it's funny how this works. If you think about Moore's law, it's basically describing the number of transistors on an IC, those doubling every two years. But it doesn't address expansion in the ways we use our technology. If new machines come out which allow us to stack even more GPUs into a single machine, performance capacity per cracking host will rise even farther than double per year.

One person estimated an 8-GPU cracking machine two years ago at about 539 billion hashes per minute. At 128k hashes for one password, you could make about 70,182 attempts per second.

But here[1] is a five-machine cluster from a year and a half ago with 25 GPUs. Its speed? 63 billion per second against SHA1. This results in 492,187 attempts per second. Assuming SHA256 is about 50% slower, this would be around 246,093 per second.

Some password dictionaries contain millions of words. But if your password is '0Password', it'll probably be cracked in a couple of seconds on modern hardware.

[1] http://arstechnica.com/security/2012/12/25-gpu-cluster-crack...

Might be able to get an idea if you go through old SBIR's

I actually think this is quite clever. It's not a tech improvement but its a domain shift that fits well. I took something from it, in a different way than other clones did.

His combinations make no sense. Just a random strings.

How can you tell if a process runs as root or is run within a sandbox?

"ps" will show the effective uid ocspd is running as:

    % ps aux|grep ocspd
    root              534   0.0  0.0  2442712   2036   ??  Ss    3:53PM   0:00.04 /usr/sbin/ocspd

I don't know how to show the sandbox a running process is contained in, but it's easy enough to show that launchd runs ocspd directly, without sandbox-exec:

    % grep -A3 ProgramArguments /System/Library/LaunchDaemons/com.apple.ocspd.plist
            <key>ProgramArguments</key>
            <array>
                    <string>/usr/sbin/ocspd</string>
            </array>

It's possible for a process to programmatically place itself in a sandbox (see /usr/include/sandbox.h), but a quick look at the source to ocspd and a quick disassembly of what actually ships with OS X 10.9.2 shows ocspd does not do that.

On a mac Activity Monitor will show you that, also there are also things like top, ps aux and pgrep. These would work:

pgrep -lf -U root | grep processname

or:

ps aux | grep root | grep processname

I just clicked and held the middle mouse button to move to the right smoothly.