typicalrunt

Please fix the spelling in the sidebar.

Recieve a digest of my best content every month about software, startups, and life.

"Recieve" should be "Receive"

Since this is in the sidebar of your site, it stands out and puts a negative spin on the rest of what you have to say. Unfair? Maybe, but this is such a basic error that people will judge you based on such a basic mistake, simply because it will be easily caught by any spell-checker.

I'm curious other security conventions will take the same stance.

[1] One year a reporter disguised herself as an attendee instead of admitting she was a reporter, and was attempting to get hackers on record saying that they've hacked into <this> and <that> important system. She was found out and summarily chased (literally) out the convention.

I really shudder to think what 10-20 years will do to a city where the middle class (whatever that word means nowadays) has been completely hollowed out.

[1] http://www.vancouversun.com/news/East+Families+leave+Vancouv...

[2] http://www.cbc.ca/news/canada/british-columbia/story/2013/01...

Not yet. This first run will be the regular vegetarian soylent, but it is lactose free, kosher, halal, and absent of all known allergens

I believe soy is an allergy to some people. What does "absent of all known allergens" mean then?

Congrats to Tesla for turning their first profit!

The Iron Ring is worn on the little finger ("pinky") of the working (dominant) hand

The former is a question about fundamentals, whereas the latter is a question about specific implementations. I agree that as a Web developer you should probably need to know what JSONP is, but it's also something that could be learned in about 5 minutes from Google.

I like it when a phone interview is basically a conversation. I don't like Spanish Inquisition-style interviews, so I like to start with something and watch it lead to other things. Of course, if the conversation drops dead I can refer to my notes and ask another question. With regard to the URL question, in the past I have allowed the interviewee to answer the URL question as best they can, and the ask questions to cover some of the gaps, and these questions can lead into JSONP handling and its ilk.

As an aside and a <rant type=small />, interviewing like this ensures that there is a natural flow and I'm keeping my interviewee's brain jumping between similar contexts. I hate it when I've been interviewed and I'm expected to context switch between algorithms (mergesort) to best practises (SOLID) to programming (implement REST with Jersey+Servlets). And this is all in a 30-60 minute "conversation".

The reason I interrupt them when talk about electrical signals starts (or, as you mentioned, typing a key), is that I mainly hire for Web development positions and would like candidates to understand how the Web works. This knowledge is especially important for when things break down. Knowing how electrical signals work would be useful if you had to do hardware, networking, or anything else, but I just want to know that a candidate isn't just creating Web services without realizing that latency exists because of DNS routing and network hops.

Edit: clarity

I put myself on sabbatical after realizing that my needs were not being met on a regular basis by my job. While I'll allow short-term ROI to be negative, I will never allow my long-term ROI to be negative [3]. I took some time out of my life to spend it with my wife and young daughter, something which I'd never done in my life. It is a blessing.

However, in the first week of my sabbatical I get called up for an interview with Expedia for a senior Web dev position. I thought "hey, I've never worked in the USA before, this could be fun". My interviewer was a junior dev who, in the course of the interview, demonstrated that he had very little experience in interviewing (whereas I have conducted > 100 interviews). In the technical phone interview I was asked some esoteric questions about finding the intersection of two integer arrays, what the O-notation would be, and so forth. I came up with some half-assed answers, since it had been years since I thought of those things [1] and since I was tired (on sabbatical) and didn't care if I got the job I asked the interview plainly how often this type of problem comes up in his work routine. His answer: never. Not once. I mentioned to him that I don't understand asking these types of questions, and I have never asked something like that in an interview before. I thanked him for his time, and prompted removed my resume from the application process [2].

To wit, my phone interviewing tactics for a Web dev position contain the following questions:

    - when I type in a URL in my browser's address bar, press Enter, and then the page appears, tell me what happened technically in as low level as possible.
    - what are the main verbs used in the HTTP protocol.
    - something about CSS, JS, <backend language>, HTML
    - something about how to handle a situation like breakfix, sensitive data leakage, etc.

[1] In other words, I think of O-notation in the back of my head when I code (loops within loops, etc), but I don't lead with it.

[2] Oh my, they did not like this. Granted, I was working through their internal recruiting agency, but you'd think I just called their child ugly or something.

[3] That's my corporate-speak coming out. Basically, short-term negative ROI is akin to working really hard and losing a bit of sleep to see a project to completion. Long-term negative ROI is when the hard-work you are doing is not noticed by upper manager and you are passed over for awards, congratulations, and other extrinsic things.

Edit: clarity

1) For monitoring applications like Chartbeat, IIRC they count a user as concurrent if they are on the site anytime within the past 30 seconds. 2) I've seen real-time monitoring systems count a concurrent user as any visitor in the last 5 seconds. 3) Lastly, the only real raw numbers that I've seen are the traffic hits through an F5 load balancer to a set of backend servers, and that is the only number that will give you an unbiased # hits per second in real-time. Unfortunately, this amounts to requests (HTML) to the server and may not be a 1:1 ratio with users.

So in terms of what I've seen, it depends on the type of calls and the application. For the EA forums (forums.ea.com) which I was in charge of up until March 2013...

For #1, forums would regularly reach 15,000 on the launch of a new game. We would sustain that for ~12 hours [1]. On just an average normal non-event day, it pushes 3000 concurrents. For #2, I've seen something north of 3000 for EA forums. For #3, the F5 would report peaks of 200 requests per second.

When I built the Campus Wide Login (http://www.cwl.ubc.ca) SSO auth system for UBC about 11 years ago (still in use today) we would have almost 50-75% of the full campus using it at once, which is about 30k concurrents (unfortunately I didn't have access to the numbers over the F5 LB). However, most of these calls were for the HTML which then went through an SOA (XML-RPC, ugh) architecture, so I'm sure the req/s was much higher on the XML-RPC backend.

[1] this is a feat in itself because most of the forum data is not cached because the business wanted the data in real-time, so the read databases would receive a lot of traffic when the web servers spiked.

Edit: formatting

And the kicker of it all is that the average family salary is a laughable $70k.

Protecting the data is called a disaster recovery (DR) plan in those big outdated companies that people like to make fun of.

The reason that these companies have a DR plan is to tell the CEO that 'when' (not 'if') all of the data goes away, (a) how long will it take to get it back and (b) how out-of-sync will this data be (2 minutes from freshness? 6 hours?).

I've seen companies (gaming companies, mostly) that display tweets as endorsements for a game and then, when I try to find the tweet in Twitter, that user mysteriously doesn't exist.

However, for anyone with the ability to learn a technical command line operation, the thinking goes like this: first i want to convert the output into another format, then another format, then sort it, find a count of the uniques... and so on. It reads very easy because each tool is doing one thing in the chain.

High priority: call me or use some other synchronous communications protocol. Everything else: email, ticket please. Async is better.

I'm used to working in geographically separated teams in different timezones, so starting my day 2 hours ahead of everyone else is no different than me working in a different timezone. Once you solve this problem, you have solved the majority of your communication difficulties.

At my office most people get in around 9:30am to 10:00am, and leave around 8 hours later. What I found was that I couldn't get any work done around that time because productivity slows down to a crawl in the middle of the day, usually due to meetings, figuring out what they need to do for the day, or the usual inter-cubicle communication.

I fixed this for myself by coming in early, around 7:00am. That means I have approximately 2-2.5 hours of uninterrupted time when I have peak energy. Then when everyone gets into the office I don't mind the interruptions. Those are the pros.

The cons are that I have to wake up at 6am to drive into the office (~40mins drive). As well, 8 hours from 7am is 3pm, but there's no way I can leave at that time without losing face. Instead, I leave at 4pm. I currently rationalize this extra hour of "work" by saying that I take a 1 hour lunch that I don't charge for.

Timeboxing myself into a 8-9 hour timespan means I really need to prioritize my work for the day. Once the clock strikes 3:30pm, I make it a mission to take the next 30 minutes to wind down and prepare for the next day. This has helped me reduce the stress associated with the work day.

Maybe I'm just too jaded...

I've been doing this for over 10 years, starting from when I realized that I was getting sicker and more unhealthy just sitting at my desk for extended periods of time (> 4 hrs straight).

If I am a recruiter or any potential employer, I can now instantly see what this applicant wants and expects in the form of compensation, and it is now my job to exceed that compensation and entice this person to come work for me.

If I don't want to meet his target salary, then so be it, I go my own way and he goes his with no love lost. I find this type of discourse very refreshing.

Huh?!? I'm always amazed at the ease of fear-mongering that some people come to. The squatter didn't break into an occupied home (assuming he broke in at all), he occupied a vacant abandoned home. At least he's trying to publicly live there and make it his, which may help reduce more malicious squatters from occupying that home and using it for criminal purposes (this has happened with abandoned homes in Las Vegas, NV).

At least now the neighbour can claim a 100% occupancy rate in the neighbourhood, and not one where there exists an abandoned, foreclosed home.

Funny you say that. And incredibly sad too.

I have participated in interviewing many junior/mid/senior developers and you are correct that they trip up on the % operator. I've also experienced them tripping up on the word "modulo" and instead trying to calculate the remainder of a division operation by hand.

While not trying to be elitist, I'm not sure what it says about our industry when a fundamental concept such as modulus is not understood by programmers.

I'm not sure if it's due to someone's lack of technical ability, or if they get distracted by other externalities, but we always tend towards something that seems really simple at first but instead incurs a lot of technical and process debt later on.

Brilliant read.

Visting cities in Europe is actually a very good way to design versus evolution. Cities that evolved their city are relatively easy to find. However, if you want to see cities that were designed, you only need to find the cities that were flattened in WW2, such as Rotterdam.