I know how they work though so here's one example. It all depends on the clients SLA but let's say the client has 99% uptime, 24/7 on-call duties in their contract.
In that case one person out of 5 rotates an on-call device (phone) every 5 weeks. In the strictest of SLA they're required to respond within 15 minutes and sometimes have a solution within 4 hours. This varies wildly from contract to contract.
Of course an incident manager is available, redundantly, and is tasked with coordinating skills between departments to solve an issue within the designated SLA.
Alerts come into the device and the tech can respond to alerts directly via the device to acknowledge, force re-check or simply disable. There is also a more featured web interface for the alerts to access via a browser.
Alerts are sent with SMS through a self-hosted gateway. Directly attached to the monitoring server, not using any e-mail translation API.
Alerts are logged, and in some cases a ticket is created for an alert.
Preferably a manager should work out the on-call schedule, but techs often trade weeks and are more than capable of handling it themselves.
They receive an added monthly compensation including overtime. So any work must be reported in a time reporting utility to eventually lead to payed overtime depending on the contract it pertained to and the time when it happened.
Why? It says a lot when a company doesn't put the effort into various forms of testing and QA to ensure that production software does not have critical issues that warrant at 2am call. Unit, functional, integration, load, and simulation tests should be written for every single piece of critical infrastructure. You should be hammering these things in staging environments with 10-100x of your normal peak load.Use something like Gore to replay live traffic against a version in staging or QA environments. Yes, that takes work, but to me it's better upfront than to wake me up in the middle of the night or to know that when I go home I have to have my phone around me at all times. The business should care about these things too; it's their product and they should care enough about you to make sure good processes are in place to ensure quality production software.
That said, when I was at non-on-call companies there are definitely times when something does happen that warrants immediate attention. Generally someone in operations would get the first call, they check logs, diagnose the issue, and call a developer familiar with the app that's causing the issues if that's the case. I don't mind waking up because I know it has to be something serious that slipped past our processes.
Outside of the regular work hours you are only expected to work when an alert / call comes in. If at all possible you should fix it, if it would take > 1 hour you start looking at temporary workarounds that will hold until you are back at the office.During regular work hours on-call tickets always get priority.When problems arise with external dependencies we open tickets in their support system and wait for their response.Most important in our case is to keep the support desk up to date so customers don't open too many tickets and to let people know we are working on it.
Depth of on call work depends. It usually consists of rebooting / restarting services and checking if they come up as expected and trying to find the root cause of the problems. If the root cause can be easily identified and fixed, fix it immediately. Otherwise, open a ticket to fix it asap.
You are required to respond to calls within the SLA, and work on problems until they're fixed (definition of fixed being service restoration - root cause canalysis for complex problems and hence fixes will happen during normal hours) or until you've been working long enough you need to be spelled.
If you're on-call you're still expected to be doing your day job, but production takes priority, and projects are expected to accomodate that.
On-call rotation is generally rotated around teams, so one week in 4 - 8 depending on team size.
Our team is heavily silo'ed, and each developer is responsible for a specific set of code. Since we have gone through a bunch of reductions and reorganizations, this ends up meaning that often one person is responsible. Our customer is a 24/7/365 operational unit, and it is our only customer.
So, the end result is any given developer is on call all the time, with no pay compensation for that at all. Not only that, but you should expect to be called about not only a defect, but in cases where the customer is trying to use our software in a way it was never designed to be used. So, get a call at 2 AM on the weekend and design and implement a new feature, release to production to debug and test.
I really dislike the way we operate, and recently the entire QA team was let go so I have a feeling things are only going to get worse.
On-call is unpaid and no additional bump if called out or public holidays. No additional vacation in lieu either :(
- Expected duties are to fix the issue and bring production systems back up, all engineers have context on production systems and can escalate if any additional context is needed. We have an established workflow of steps to take to determine root cause. We can also directly ping all engineers to provide additional help should there be a critical issue with a system you are unfamiliar with.
- If you are on-call, the on-call duties come first and foremost above everything else. Expected response time is 10-15 minutes from issue raised at all times.
- Mitigating risk is via communication and getting enough context to know the bad outcomes and how to mitigate any issues.
- On-call rotation is very arbitrary and undefined (we have five engineers who can do on-call duty), we try to share the duties equally but some get assigned way more on-call than others. (I was on-call most weekends last couple of months and all throughout the Xmas period for example)
- 1 week in 4 Monday 00:00 to Sunday 23:59, with a fixed pay adjustment (same fixed amount added to our salary every month, not a % increment).
- If you get a call, you're on the clock and get paid regular over-time rate. Theoretically this only applies if you get called and are doing something for more than 30 minutes though.
- I know most of the on-call managers personally so don't mind picking up the phone for a quick opinion for free, if it's at a reasonable time.
- Online within an hour once we've picked up the phone.
- Senior on-call manager gets woken up by Ops first and then will decide which parts of the system are affected. After going through known issues and work arounds will then work out which part of the system needs to be looked at and makes the call to the on-call developer that is appropriate (ie. which team).
- Duty is primarily to diagnose and provide knowledge to the on-call manager to make a decision so service can come back up again.
- Don't do code fixes (J2EE on my team, mix of Java and C++ on others) - we have far too much to go wrong for hacking around like that, but may do config changes and some scripting. The line can get a bit blurred.
- In our team we should raise a ticket/Jira for every time we get a call so that it's visible to everyone what happened and see where our pain points are.
- During office hours, Production issues are distributed in the team in the same way as bugs, according to domain knowledge and individual capacity.
- We tend not to get called out except for when we do installation in to Production. We have a fairly heavy weight process for releases - which we are working on.
- I am at least 4 levels of communication away from any customers, including 1st and 2nd line teams.
You are expected to answer the phone promptly, be sober and do anything to remedy the problem including reaching for other people that can fix it (does not have to be a permanent solution).
Expected duties: Respond to major problems outside of office hours, in response to a phone call. Be online fixing the problem within 15 minutes of being called. Typical workload 2 hours per week. Be somewhere with a reliable internet connection, and where you can stay even if an issue takes a few hours to resolve (no mobile internet from campsites). Be sober.
Fixes: Because of the need for code review and second testing, emergency code releases never happen out of hours. Instead, all code deployments include a backout plan, which reverts to a known-good version of the code (not a bug-free version, there's no such thing, but a version that hasn't caused major problems when run for several weeks). Data in the database may need to be manually fixed.
If you're patching an issue by deleting some bad data, and in your judgement deleting the data might delete evidence needed to identify the root cause of the problem, try to identify the root cause if time allows.
Priority: On call is only called for major problems - either their software has raised an alert saying they should be called, or there is a problem costing thousands of pounds a minute such as "website down", "customers cannot place orders" or "customers will not receive orders".
There isn't a formal SLA, but as it costs thousands of pounds a minute the expectation is to fix as fast as you safely can, without mistakes that make the problem worse.
Escalation: To their team leader, or to some other senior software engineer on their team (our team leaders have all been senior software engineers on the team they lead)
APIs down: In a rather old-fashioned design move, all critical components are maintained in house. Contact the out-of-hours on call for whatever team maintains the broken system. If it's a non-critical component.
My company does 24/7 devops for some clientele. We are a team of 6 for reference. We have been doing this for many years since before "devops" was the term for it. Some of the platforms we have also built for these clients, and some we simply manage, or we have only built+manage the automation.
In terms of answering your question:
- expected duties. In terms of what we are selling the client there is a long specific list of what exactly we can provide the client. In practice however the list is exhausting, and intended 1/2 for CYA, and we will fix whatever issues arise. Some of that is seeing things that need work/adjustment/tuning/optimizing before problems arise, and then as you can imagine the whole being-on-call thing means that you must be an expert at resolving issues that no one saw coming. In terms of SLA stuff, we are supposed to be on-scene (digitally) in 15 minutes, but we are never that slow.
- how deep. Think of it in phases. When something needs fixing, you must quantify the urgency. If there is an urgent fix needed this is ground zero. You do whatever you can, if that involves waking people up, or checking out code bases that are new to you and patching some developers code in the middle of the night, its all on the table. In ground zero mode, you do whatever it takes. Once the bandaid/fix/solution is in place to "stop the bleeding" as I like to say, then there is follow ups, that may include working with the client to have them implement the elegant permanent fix, or if they are in over their head, sometimes that lands on us too. But it serves no-one to have a bandaid that is going to just get ripped off every night. So we see the problem from A-Z, even if our offramp is on B, or M. If it's not urgent, we will just wait for tomorrow to discuss with the client, it falls out of the scope of on-call.
- priority. Well, on-call work is billed and agreed different to ticket work since we are primarily a consulting company. So these are different buckets. But we also have our own products that we own 100%, and the priority is quite easy. If something is broken/down/about-to-break, it trumps everything else. Regular tickets are great, but they are meaningless if the platform for which your developing them against can't stay functional. On-call work rarely has a "queue" or even really a ticket system.
- there is no "complete in time" it's either done or you failed. I say this, having failed too, and it sucks, but it is what it is. If something breaks, and you can't fix it, you don't just go home. But.. sometimes you do, but you walk away from the scene with your tail in-between your legs, no one plans for that.
- managing other teams risk. Communication. Putting energy in ahead of time, and bringing things up before they break is huge. Also if you say "Hey you should turn left, there is a cliff!", and the client is insistent on turning right, this can do two things. A - they know and hopefully its recorded in an email or in a meeting that you wanted to turn left. B - if your absolutely certain they are going to run over a cliff, but your still on the line / have to support the darn thing anyway, you can quietly put a bunch of pillows at the bottom of the ravine, and prepare for the inevitable. When the car goes over the cliff, and everything almost grinds to a halt, and you manage to have been correct about it, but also managed to bail them out, you score a lot of gratitude from the client, and ongoing future relations.
This is all from the point of "consulting" mostly, but I have done this same type of work for many large companies directly on their payroll too, it all applies, and the bigger the company the more it's like consulting in some way also, because bigger companies are more compartmentalized. I have also done this in many small startups where your all just one small team.
Holidays and vacations are important, but they will never truly be the same after years of this. We are pretty good at it now, and we really do try to keep everyone up to speed with where "the bodies are buried" with all of our clients infrastructure. That is the hardest part. Everyone can look at a perfectly groomed wiki or set of 100% refined chef/puppet cookbooks/modules, but the world isn't perfect. So the hard part is learning how to take the punches with elegance, and people need a break. It really does take at least 3-4 people to have a not-insane 24/7 schedule.
We generally plan about 1-3 weeks ahead depending on the time of year and put it into our scheduling system, which is also the system that does our paging. We rotate weekends, and work it out amongst ourselves. Some people have things like date nights that we know about and try hard to not screw up.
Don't build your pager system yourself, you have enough stuff to do. I won't plug them because I don't want this to sound like an advert, but do yourself a favor and pay the money to a company that specializes in bubbling up alerts to notifications that can do phone/sms/email/ios/android/push/etc. These have really helped us manage the insanity & schedule.
If there is any advice, simply don't be frightened to say when you don't know something, even if your tasked with fixing it. There is little room for ego when your the one that ultimately has to be responsible. Being on call means you can't pass the buck, and the sooner you know what you don't know, the sooner you're able to learn it!
> expected duties (only answer on-call, do other work, etc)
Only answer pages. My employer did shifts a bit differently from most companies - only six hours per shift, no fixed schedule (decided a week in advance) and only outside of work hours (pages during work hours were handled by whichever sysadmins were on duty), which worked quite well to avoid burning out sysadmins. On-call shifts were paid, and shortages of volunteers were rare.
I'd expect to spend maybe fifteen minutes per shift fixing things, on average (this is in managed hosting, so a page could be any of our customers' services).
> how deep does your on-call dive into code to fix, vs triaging, patching, and creating follow up work to fix permanently?
In my case (sysadmin for a managed hosting company) the code involved was often not under our control; the standard practice was to escalate to the customer if the cause of the outage was a bug in the application. The usual process when suspecting a bug was to track it down if possible (the codebases were usually unfamiliar, so this wasn't always the case), work around it as best we could (e.g., temporarily disable a buggy search indexer which was leaking memory, et cetera), and then get in touch with the customer (by email if the workaround was expected to last until work hours, by phone if not). Occasionally I'd fix the bug in-place and send the customer the patch, but this was technically outside scope.
> priority order of work (on-call tickts vs regular work vs existing on-call tickets vs special queue of simple tasks)
The only priorities were resolving the pages at hand and arranging followup where needed (usually raising a ticket to be followed up during work hours).
> what happens when the current on-call can't complete in time?
Generally the on-call sysadmin would resolve whichever pages they had acknowledged; in the event of an extended outage the acking sysadmin was expected to brief and hand over to the person on the next shift.
> how do you manage for other teams' risk? (ie their api goes down, you can't satisfy your customers)
In practice, we could escalate to anyone in the company for a serious outage we were unable to handle ourselves. This was pretty rare, as a small ops-heavy company, but everyone had access to everyone else's cell phone number and an outage-inducing bug was usually sufficient cause to wake someone up if it couldn't be worked around.
When we got called out we were well recompensed at minimum of two hours of 3x hourly rate. If you resolved incident in 10 minutes you still got 6 hours of pay. If you got another call within those first two hours then you didn't get anything extra until you were working for 2 hours and 1 minute , but if the 2nd call came in after 3 hours you started the clock again. During times of instability (new code release) we often had management agree to you working from first call-out until the day shift came in to order to minimise downtime. When we were working during the night the on-call always had priority, but if you were sat around waiting for the system to do something then we all did something else to keep us awake. But there was no expectation that it was other tickets or project work. We made personal choices of doing day work or it could be crossword puzzle etc.
We all had areas of expertise and if you caught something you didn't know how to resolve then we had the authority to ring anybody. And that person would also receive the same compensation. In 5 years doing this I never had a complaint from calling somebody else out. Did we get tired yes? Most of us had project roles or team lead roles during the day but we all knew that the production system had priority and we and our own line management would deal with the project work accordingly. Did we get burned out on this? No because the rota meant that you still had a life. If you were top of the list and had other commitments that night you'd negotiate coverage with somebody else further down the list to see who could go top for the night.
My employer did this because the cost of not doing and having downtime during the day was a lot higher. If the system failed out of hours then it could impact our business and we could lose c.8,000 hours of day shift working time that would still require salary payment. Plus reputation damage etc. Most I ever accumulated over a weekend was 32 hours at 3x (situation so bad required to restore database to last known good and then catch-up log files).
One night I also got it wrong and in trying to correct the incident forced us into a situation when we had to do a database restore. That caused about 4,000 man/hours of downtime. When my bosses boss came in at 6:30am (he got called out by my boss) I got sent home being told I was too tired to continue support, day shift staff would take over and the missive to ring him when I had slept. I made the phone call expecting a significant dressing down only to be told, everybody else who looked at the diagnostics said they would have done exactly the same, we've all learned, and you stay top of the list tonight so that we know you're not scared to get back on the horse. Truth be told it did knock my confidence and anything that was a little out of the ordinary after that I always ended up calling somebody else for a consult. After a while I engineered my self off the on-call list.
- Rotations are mixed, consisting of weekdays and weekends. In other words, if you're on-call M-F this week, in a few weeks you'll go on-call over the weekend.
- If the on-call engineer does not pick up, the incident is escalated to the manager, then their manager, all the way up to the CTO. Some teams have secondaries before managers are involved.
- The on-call engineer would normally work off the regular backlog. We have talked about pulling them out to work on on-call + tech debt exclusively, but there hasn't been enough on-call churn to justify this.
- The on-call is on the hook for resolving the immediate issue. In many cases this does not mean actually fixing the underlying problem. Those get written up as tickets to be prioritized as part of the backlog.
- The priority is determined as a team. As a manager, I encourage the team to aggressively tackle on-call issues, don't want to be a blocker for that. If something consistently pages us, it is guaranteed to make it to the top of the backlog fast. We have also chosen to prioritize product work over on-call tickets when we felt our pace was good and the on-call churn not too terrible. Kanban makes priority changes pretty easy.
- Not sure what you mean by "on-call can't complete in time". On-call-related tickets end up on the backlog so anyone can tackle them, not just the person that filed it.
- We have a pretty good on-call culture and the teams are very sensitive to other teams' pain. If we're being paged about an issue with another team's code (shouldn't happen too often), there's always the option to page their on-call and triage together.
- We track operational churn, send a weekly on-call hand-off email to the team with notes about the pages and steps taken, and have operational review meetings where these emails are reviewed (+ any other operational matters) and next steps are determined. Maintaining transparency around operational pain and building structure around the follow-up process has been really helpful in reducing our weekly churn.
- I think the ideal number of team members that should be on-call is around 5 to 8. Anything less than that and rotations become very frequent and a burden on the individuals. Anything more and the rotations are so rare that every on-call feels like the first time.
- Last piece of advice is to FIX THE PROBLEMS (or change your alerts). Build whatever process you need to make sure that you have plenty of leeway to address anything that pages you constantly. Don't get overly attached to the alerts - you might find that changing sensitivity thresholds or deleting the alert altogether might actually be the right answer (please don't do that for the wrong reasons though :)). If you're paged for a bunch of things that you can't fix, you're probably doing it wrong. Just like technical debt, if you don't tend to on-call issues they WILL get out of hand. Picking away at it slow and steady will almost certainly help reduce it from a torrent to a trickle.
N.B. I work at PagerDuty. A bunch more suggestions here: https://www.pagerduty.com/blog/tag/best-practices/.
On-call fixes until the crisis is mitigated. If something can be addressed the next day during normal hours, it is.
On-call tickets are the most important. In our company, "on-call" just means you get the infrastructure alarms for that week and time period, and gotta deal with them when you get them. There is no alteration in pay for on-call weeks.
If the current on-call can't respond within 10 minutes (or forgets to ack in PagerDuty), the next person on the escalation schedule will be notified and expected to deal with the issue.
Other teams' risk is mitigated because if it's breaking production, we just call them and make them fix it. The whole company is "always on-call" in some sense, because if your thing is breaking production, you're going to get a call and get asked to fix the problem.
We feel like the tooling on this, even with PagerDuty whose whole job is managing on-calls, is subpar and are constantly talking about creating an in-house replacement.
It is unclear whether this is ffmpeg-specific, or something the HTTP live streaming protocol actually requires and therefore potentially of wider impact; I can't find any obvious reference to this feature with either a quick Google or a skim of the Apple RFC. Does anyone know?
I've had periods where the idea of working another day with arrogant dickhead 'know it all' ex-Physics students turned developers who can solve tough problems with terrible to maintain code thus making themselves unsackable made me think of jacking it all in and moving to a third world country and living in a hut - even to the point of visiting the Vietnamese consulate for information.
Likewise I've had times where a young CS background developer who is eager to learn, very gracious, fun to be around and delivers makes me remember that it can be a great industry.
I'd recommend getting out of your current job if you can if its making you feel this way.
A few years ago I was working in finance, had experienced some workplace bullying so I overworked to prove myself to stop it despite it being about an Alpha boss picking a scapegoat, and I suffered from some mid strength burnout and in the end I wasn't fit to work for probably 5 months afterwards. I ended up going into a completely different industry (but still software) and managed to reboot myself over about 3 months and started to enjoy work again.
Earlier in my career I met someone who had completely burned out. He'd not worked in 18 months despite having lots of offers, had moved to the coast and was just doing spiritual stuff all the time and was burning through his savings. We asked him to come in for 1 day to interview others and after 2 hours he said he couldn't take it anymore and left, and that was it. It was quite shocking to see someone who was that way and quite scary when I felt it happening to me.
Don't wait until you completely burnout because it will damage more than just your career - your health, waistline, relationships, friendships, bank account, future employability etc.
A year and a half ago I saw my wife studying a textbook on Anatomy & Physiology. I started reading it. I thought "OMFG this stuff is amazing! And it can't be learned in 3 days (unlike all these 'hard' problems we hackers like to discuss)."
Now I'm going to school for a career in nursing.
There are also some doing more hardcore scientific stuff , like better diagnoses using eeg analysis, but those requires fda involvement , deep pockets , patience , deep knowledge , etc - so those innovations come from universities, when/if they come.
Also Alphabet is going to that field, it recruited a high official from the NIH in mental health. This again shows you how hard is to start such projects.
The big players have a lot of money invested in exactly-wrong theories and approaches to mental health.
here is the clickable link: http://bit.ly/22W9Of1
What would I do? I'd shut it down and give the money back to the shareholders.
But normally I just tell the senior guys what's wrong. As a month-old employee, I once emailed the COO at 2 AM telling them we could use the technology to rate sites and make millions.
COO was not impressed but he liked employees speaking up and encouraged me to email him more.
Your wife should consider sending in an unsolicited resume to be a no-op and, instead, start meeting people who either a) are hiring managers or b) can refer her to hiring managers.
Her goal in achieving connection with the hiring manager is to secure a coffee date or other informal conversation. Her goal for this conversation is qualifying the company, impressing the hiring manager, and convincing the hiring manager to either invite her formal application or respond positively when she suggests moving to a formal application.
This is one of the huge knowledge gaps in the engineering community regarding getting jobs. Unsolicited applications are not how most people get hired. This is particularly true of smaller employers.
I don't have a valid working visa in the US and have been applying almost exclusively to American companies.
My "interview" rate is 10%. 100% if it's with people I know, even if I'm completely unqualified.
My "rejection" rate is around 50%, within 2 weeks. I assume the rest won't say anything if they reject.
General job sites (the ones where you can also apply to be a carpenter, etc) are a waste of time. They probably get so many resumes they end up tossing half of them.
Stack Overflow Careers gave me an awesome ~30% of interviews. As in I applied 6 jobs and 2 interviewed. Both of them were jobs I didn't fully qualify for.
Generally, direct emails gave me a 100% (5/5) response rate. An email, like firstname.lastname@example.org, not a form. Email lets me mention in subject line that I used to have a startup, so I stood out. Most of them rejected on lack of visa though.
I do spend ~10 minutes per cover letter. I really dig deep, like an investor would. I convince myself that I'm doing the company a favor by joining before writing the letter.
In the end, you just have to convince one company. If you have a lead, immediately latch to it... do research on the company, the interviewer, and write questions.
There's a certain bar you have to cross to convince people to hire. It's better to optimize for a few companies than to try to reach out to as many as possible. If you feel unworthy, then optimize for the lower tier companies who have lower standards.
1. Do not apply 100+ companies. Select max 3-5 of them. And research them. Get to know people working there. What are their problems? What tools are they using? What meetups can I meet them? Are they active on some online community? Get in touch with people there. Just talk and show interest in them. It always good to know the company before applying and dropping it, if it's not a great match you can drop it. (Just like dating, get to know them before you marry them.)
2. Fine-tune that resume. I didn't see your wife resume but I am sure it could be improved. Here are some very fine tips : http://www.slideshare.net/perlcareers/how-to-write-a-develop...
3. Build some portfolio. Anything is fine. Really. Just showcase that she understands/can write code. She can join on some open source community or just build something on her own. Better the first one, because she can be mentored and demonstrate teamwork.
4. Blog about it, the learning experience. This about as much about showcasing work as communication. If she can communicate effectively that counts as much as programming. (Actually more if she really great communicator.) Don't be shy on this.
5. Repeat from step one.
And one last thing. It is not just about what your wife wants, please be considerate about the company needs too. I know a lot of company that would be good for me, but for the company I would be just a drag. That's how it is.
She has a LinkedIn profile, with relevant skills highlighted.
She is not active on Github yet - that will be her focus now. She was focusing on sites like HackerRank and CodeEval so far.
If she finishes any projects, we will definitely post it to HN for feedback.
We are trying to find more back to work sort of programs - a lot of banks seem to have them, but the cutoff date for applications seemed to be the end of last year.
We do have friends working in the industry, but most are at large companies where its hard to bypass HR and go to the team required, or companies where hiring is currently frozen, and so on..
We are going to try to find Hiring Managers to talk to or have a coffee with - if any of you guys are looking to hire an highly competent Python/Java programmer down on her luck, or would just like to talk, shed love to talk to you over coffee anywhere in the Bay Area. Please send me an email at (username) at gmail if you'd like to talk.
Its great to see the support and advice from everyone here. Really, thank you.
H-1B is known to be a sort of lever that employers can use to keep you at a job. She seems to present just the opposite, yet with qualifications which are a dollar a dozen.
I apologize for being blunt, but it appears to be an atypical, disadvantageous situation. You might do well to embrace it and aim for some contract work in the near term--none of the above will be a negative then.
Also, make sure your online reputation looks good. LinkedIn (make sure to enumerate skills) and Github are probably the two that get me the most recruiter touches.
Best of luck!
 http://www.meetup.com/find/events/?allMeetups=false&keywords... http://www.meetup.com/software/events/224734607/
I'm not in the states, so I don't know what the employment environment is like on the ground, but from what I know in general getting a job depends on who you know and what others know about you. In other words; getting employed via the traditional vanilla job application route is going to be tough. Especially for immigrants.
She needs to go out and meet people, work her personal network, and have some cool and interesting projects to hook people's attention with.
A website, an app, a repo on Github. If the answer to that question is 'No' then my assumption is either a) this person isn't interested in the work, or b) they don't know how to code in the real world and I'll be paying them to learn.
I'm constantly amazed at the number of people applying for dev positions who claim years of experience and have absolutely nothing tangible to point out.
I run a small operation so I can't comment on big firms.
TLDR: Build something recruiters can see, and preferably use. It'll put you instantly in the top 10% of applicants.
It is easier to get a job with the skills and experience you already have and then try to migrate to newer skills. So maybe going for Java & Python jobs without relevant experience is an issue.
Whilst education is important experience is far more pertinent in hiring. As is the personality factors revealed during interviews or even in the covering letters. 100+ applications suggests that there are issues. The trick is to find out where they might be. Getting some professional advice might be necessary.
If you have no friends that would help you with this, I would suggest going to local conferences and talking to speakers. On local linux group meeting, I had a conversation that literary went
me: "Hey, awesome presentation, do you think I could get your slides?"
speaker: "I don't think I want to hang them over, I might have divulged too much about our company internals so I don't really want to have it on the internet."
me: "That is a pity, good I was taking notes :-)"
speaker: "Well, if you liked it, you might want to work for us, we have a junior position open."
(Disclaimer, I was 22, still doing my masters at the time, your conversation might be different)
Maybe also take a 2-3 sentences to explain the gap, with a positive spin. "For a brief period, I was unable to work, due to visa issues. I therefore spent my time on the following independent projects: ... The visa issues have resolved and I am now actively looking for work in ... ." Or something.
I also have an MSEE and looked for coding jobs. I only had one finished website* but it was good enough to get some responses and a few interviews.
Having built several large apps which are live in the Store in both languages, I'm sticking with Obj-C for 2016. Give Swift another year before going all in.
I think one of the biggest misconceptions with the migration to Swift is that it will be a lot easier to be an iOS developer with no experience. After teaching new to programming students iOS development with both Objective-C and Swift, the actual syntax mattered very little - the underlying iOS APIs were difficult to understand.
You'll still find that many API tutorials are written with Objective-C, so even if you don't code in that language, you'll need to translate in your head as you read how to hook up X or Y to Z. In addition, a lot of stack overflow questions for common iOS programming questions are in Objective-C, so you'll at least need to know how to read it.
The reality is if you can't be proficient with Objective-c no one will hire you at this point. The more time passes, the more Objective-c code will become legacy, and the less important this will be.
That being said definitely start with Swift. It is an excellent language and is the future of the iOS platform.
Even if you wanted to learn Objective-C all the good versions of learning materials are at iOS 7 and below. Not a good choice since it is very likely none of that stuff works cleanly anymore. So, go with Swift. Yes, you will need to be familiar with Objective-C on an as needed basis, but if you learn Swift and iOS programming it will be a translation and not that bad.
I also mention FCC because they've made it so you can add your content instead of their JS content, and poof, you have a learning platform!
That may be hard without a bachelors degree, prior research knowledge, and potential academic recommendations.
One way to short-circuit this is to take your software engineering skills to a research lab and work as a research assistant.
This allows you:a) contact with academics who are doing researchb) the visibility of what research actually isc) to add value from day one
Most labs are in heavy need of software engineers to help with software related tasks.
So first focus on what type of research you are interested in (look at as many research labs in as many different disciplines as possible) and then contact them to see how you can help.
There are several pricing models one can use for small business valuation. In this case, your company earns revenue using advertising (AdSense and affiliate). Companies like this are priced differently from e.g. SaaS startups which are in turn priced differently from companies selling enterprise desktop software.
The industry standard for ad revenue companies is a 20-24x multiplier on the most recent (sustained, not outlying) monthly profits. Specifically, it would be the following:
(20..24(135/12)) = 225 - 275
There is your answer. Your company would likely fetch between 225k (cheap) to 275k (expensive). Most folks on marketplaces like Flippa (which is where predominantly ad-revenue companies like yours are brokered) would value it as such.
There are other factors which can inflate the price of your company to maybe a 30x monthly profit valuation, but in general that will be the range. It's good that most of your traffic comes from organic searches, advertising arbitrage is risky and often results in a downgrade.
Unlike S&P stocks, a small startup does not have many buyers looking into your valuation. What one buyer is willing to pay will vary widely from another.
A prospective buyer will consider things besides your revenue history. Such as operation risk, potential synergy, possible changes for growth, if you are a competitor, etc. Then there is their own financial situation, and the form you are willing to take payment (like stock vs. cash).
As a poor example, if I were to buy your site, I'd take your profit and discount taxes I would owe plus some salary for my time to upkeep it (another buyer could be more or less depending on their resources). So the profit would be down to say 80k.
From there, I note that there virtually is no growth in revenue despite the growth in pageviews. Assuming no way to fix the CPM, my worry would be whether I could get my money back, especially if there could be a real estate peak.
So average Joe like me might be willing to pay a paltry 1-3x multiple of profit* (and mostly because I don't have much money to risk). A collector of web businesses might go up to 5x, as a guess, more if there is growth.
The best companies in the world (like S&P companies) fetch anywhere between 10x to 20x+ so it's highly unlikely you get that without exploding growth.
* By profit I mean after taxes and the acquirer's expenses.
I really am not trying to be an ass, but I am trying to be honest based on my own experiences. Your business isn't worth as much as you would like, although it is quite valuable in many ways. Simply put, you don't have a $135k profit on revenue of $140k because you are discounting the real cost to run and grow the business which someone else will have to hire out at least a portion of, pay taxes on, pay state fees etc. So in reality, assuming the person is willing to assume at least 2-3 of the hats (business, finance and customer service) and hire out the technical then they may net $10-80k depending on if they hire contractors or a full time person.
At the same time like others already pointed out, it will boil down to how much is someone willing to pay. But outside of a corporation that finds your project attractive because of market fit, or leads or something along those lines, sophisticated individuals with cash will not pay major multiples for a business that is essentially only mildly profitable after they factor in costs to maintain and grow it. So your best bet is to sell to a corporation that has sunk costs already that is happy to take the extra revenue and leads and run.
Not saying you couldn't get $150k to even at the high end $300k, but it will take a special set of circumstances. Otherwise, I'd say you are looking at more like a $60k-150k type of sale being far more likely.
No matter what, good luck and I hope you can maximize your benefit.
Considering that it is worth how much someone is willing to pay, might be a great place to some benchmarking.
(Sorry, I have only more questions, no solutions.)
Independent invention is a defense against a copyright though.
* works as well as Windows or OSX _out of the box_
* is beautiful and usable
It just doesn't exist at the moment unfortunately, but I'm confident PapyrOS, Pantheon or Cinnamon will come to solve this soon.
2. Customer journey automation tools. Autopilot is really good but its good to see competition in this area
3. Something that makes the burden of making data more accurate at the logging end better to report to business intelligence tools
4. Something that allows me to leverage my knowledge expertise as a consultant and better helps me deploy group coaching and accountability. Again there's some software out there for this already but nothing I like
6. Most important. A really good CRM. I've tried soooooooo many. Not a single silver bullet solution. Can't believe it given its 2016.
For what it is worth, sometimes my search string is as follows (India related). As you can see, I am searching for narendra modi minus major news sites. narendra modi -timesofindia -ndtv -ibnlive -thehindu -Firstpost -facebook -indianexpress -hindustantimes -news -indiatimes
One app which I can use to sell things, buy things, send messages, review things, control things, get notifications, track my health, learn things, etc.
This doesn't seem like something that would be too hard to do, considering that all apps pretty much do the same things. But that would make people's life so much better.
In fact, I've started a project to make that a reality.
W3Counter is completely passive -- no new code or features in over a year, no customer support load, autoscaling frontend (EC2) and backend (Aurora). Improvely gets feature updates a few times a year and has some light e-mail support load. I continue to have no employees or contractors.
Trying to diversify more in 2016.
My new project http://timeblock.com that are funded by that income and that I do not write any code for has generated app. 2000 in recurring revenue last year although it is not passive yet it is MRR :)
I guess it would only loosely be called "passive" as I spend a lot of time on it. But, I can take vacations and it continues to earn... for a while :)
I also work on a full recreation of the website, because now i only make a small part of my target audience happy, the rest only clicks a few times and comes again after a few weeks.
I am afraid shipping the new site will change my income tho :/
For me, it's just a matter of what's more cost efficient. Statistically it's easier to get a job than funding. Very little of funding ends up in founders' pockets anyway.
Salaries and openings for developers have gone way up lately. Entrepreneurs need to chase the best opportunity and timing.
Also inevitably, you come across competition. Ideally you become best friends with your competitors. Because statistically, fail rate is high.
The best employee is very often someone who can build/sell something very effectively. The best employer is someone who views you as an equal, works on your vision, and admires your strengths. So competitors are often a perfect match.
If you are a dev/eng/cs guy you'll land fast anywhere, non-dev startup work (marketing/PR/social/sales/support/fundraising) will require a lot of explaining and time. You'll get there.
While amusing, seems like your video is missing A) details about the game and how to play, B) face to face with your founders, C) people enjoying your product. Also the low tier would be much improved with a digital download.
Re: the game itself, this sounds like it might work with the right group of very tight-knit friends. Kind of niche. CAH, on the other hand, seems to work even with prudish strangers because no one has to take responsibility for what they're doing. And the "Life is Life" chant seems a bit cringe-worthy. I dunno, maybe that's just me.
Games like CAH and Exploding Kittens are popular because people can and do play them with family. Half the fun of CAH in particular is getting your grandma to say something horribly offensive.
This game is more targeted at a group of similarly aged friends, and further still a group of friends who are into that kind of lifestyle (drunken shenanigans).
That being said, there is a market for drinking games, and $20 is very reasonable. Best of luck.
(1) Apply to companies that aren't software companies. I was once interviewed by a chemist at DuPont.
(2) If you're not in love with your location, move away from the big tech hubs.
I suspect hiring standards are much lower outside SF/Seattle/Boston/Denver/Austin/etc. There are so few people graduating from CS programs (and so few of them competent developers), that they can't be so picky in most of the country, far away from the top schools.
During and at the end of my college career (CS as well), I interviewed at 10-15 companies or so for developer positions. Not a single interviewer did a live coding test. Only one wanted to go over the work samples I voluntarily provided with my resume. I got offers from all but a few of those companies. I think the reason is because I'm in suburban Pennsylvania, not San Francisco.
I did apply for a job at Google once while in grad school. Did two of those algorithm phone screens. I did alright, but I hated being tested under pressure like that. If I were to look for a job, I'd rule out the software companies and tech startups that interview like that. They're not the only option.
(2) That said, do take what they're saying seriously, but feel free also to take it with a grain of salt. Generally, interviewers greatly underestimate the effects of stress (the fact that interviews are typically quite dreadful experiences for many candidates) and the sheer cognitive overload of parsing the problem statement, explaining your thought process to a person you don't know very well (and who may be judging you quite harshly) while you are solving the problem, and crucially, guessing the level of optimization your interviewer is secretly looking for (e.g. maintainability versus quick-and-dirty) have on candidate performance.
[I run http://InterviewKickstart.com for a living]
Following are some very common mistakes people make when preparing for technical interviews.
1. They code, but they don't invite feedback on their code. Nor do they compare their code with other people's code. So they solve problems, but they never know if their solution was sufficient. They don't get better, despite solving problems.
Avoid this mistake: When you prep on leetcode.com or some such, read other people's solutions line by line, understand and compare. Yes, that takes time.
2. They don't do mock interviews with practicing engineers
Avoid this mistake: Find a friend or mentor who works at a brand name company and do a strictly graded mock interview or two (or more). That will reveal a lot of things your coding practice won't. You could also practice with fellow learners (interview each other), which will help lower the stress in actual interviews (though won't be as useful as doing it with a practicing engineer).
3. They practice very few problems
Avoid this mistake: If you're coming from a top-20 4-year CS program, or you have an IQ of 130+, you won't need a lot of practice. But for everyone else, don't stop until you've practiced at least about 150 problems. Anything less won't help and worse, might give you false confidence.
And when you're in the interview, try asking the interviewer if you can solve the same problem on your computer or on a piece of paper. You'll be surprised how many people will let you do it.
Maybe you should reconsider how you apply.
Your goal should be convincing your employer that you're either a great coder or have the potential to be a superstar coder.
I have interviewed for a lot of jobs, and didn't require a technical interview for any of them. You don't have to win the interview!
I first got over it with a very strong recommendation and a top degree. They gave me a technical test and I convinced them that they should just offer me 3 months probation at half salary, because that would be a better test.
Later on by showcasing projects and convincing the employer that I was the expert. An interview would be like "Have you used Fragments?" and I'd just hit them back with every pro and con and horror stories of using Fragments. Then they give an offer without further tests.
You should think of yourself as a hacker, trying to get past the door. Instead of bringing every kind of key with you, be creative and see if you can go through the windows.
Do whatever it takes to avoid those whiteboard interviews! Convince them you're the right person before you get to that stage!
However, do remember that in order to convince others that you're a great coder, you have to convince yourself. Code can be a very emotional thing, like writing. If you don't believe in yourself, you may end up worse at it.
Avoid companies with stupid hiring policies.
It seems that these guys want you to code like they do, and they'll eventually find someone "close enough" - eventually. After wasting many man hours of interview time. You don't want to work with these guys.
You want to find a company that appreciates you for the developer you are, which appears to be someone who knows his own limitations and has ways of mitigating those limitations.
You have no idea how much that is worth. Simple mistakes like forgetting api parameters, the occasional typo and off-by one errors gets all of us. Especially in a high stress environment like an interview.
I feel that a common "you're not technical enough" to be a lazy excuse, or to replace a poorer one such as "your face didn't fit", you are too bright and will show us up, or "we liked another candidate better".
I feel your pain with the interview process. I'm a contractor and I hear lots of bullsh*t all the time from agencies and recruiters. Stick with it, and do a side project that proves to yourself that you're worth it.
sockpuppet account for obvious reasons.
A few things will happen. 1) You'll get good at interviews. 2) You'll stop caring so much about failing interviews which will combat your anxiety. 3) You'll find there is a wider range of jobs available to software engineers than the kinds you've seen so far.
Neah !! Jobs are not about the degree only, still having a degree always adds up. Try half a dozen other companies. This response is typical of small size startup who instead of inviting you for a drink invite you to an interview with their two person team. I was rejected by three companies (2+ engineers) before the present company (15+ engineers) made me an offer. It wasn't even a coding interview at all, the Sr. Engineer wanted to have a conversation for a couple of minutes.
Get to the point where you are decent at level 4 interviews and you are a shoe in for 80% - 85% of tech companies anywhere.
If you can master level 4 and harder than you have a strong fighting chance for even the toughest companies to interview at.
Another thing to note you only really get level 3 and 4 interviews with top tier tech companies generally in the Silicon Valley area and maybe started by or around people from [insert college with top tier CS program].
Having deep knowledge of your specific domain (web development, mobile development, etc.) and basic data structures and algorithms (up to Level 2) will get you offers in any tertiary Tech scene i.e. Austin, Texas or Atlanta, Ga.
Source: I have gotten offers in both of these areas with just that level of knowledge.
But if you want to make sure you can get a job in the valley you got some work cut out for you. It aint the best for no reason.
Edit:I'll leave you with one more thing.
One of the authors of Programming Interviews Exposed them self was rejected by Google his first time...
let that sink in.
Try these tips.
Doing actual interviews is by far the best way to practice interviewing. And I find that taking interviews less seriously actually helps me keep my composure during interviews and allows me to perform much better than back when I first started interviewing, when I was treating each one like some kind of a once-in-a-lifetime opportunity and stressing myself out unnecessarily.
Software is a seller's market right now, and there's no shortage of companies that are looking for great developers. As long as you keep interviewing, you'll keep getting better at interviewing, and eventually you'll become good enough, or get lucky enough, to land an offer that you like.
P.S. I really like the way TripleByte does their technical interviews, offering each candidate a choice between a live-coding track and a project track. Unfortunately, having a choice in the interview style isn't a very common hiring practice, even among TripleByte's own clients, who tend to then turn around to grill TripleByte-referred candidates on algorithms in live-coding sessions anyways.
Does anyone know of some kind of a job board that allows filtering by the availability of a take-home project as an alternative to the traditional interview?
Eventually, I want to stream myself working on side projects, so I can say to companies: If you want to see what I've worked on, take a look at my GitHub/LinkedIn/Website/Resume. If you want to see how I work, take a look at my streams. If you like what you see, feel free to contact me to talk about opportunities and make me an offer. If I like your offer, I'd be willing fly over and meet with your team to see if we can get along, but the moment you start trying to grill me on my ability to solve obscure algorithms and data structure problems under pressure, I'm outta there.
If you set lower expectations people are more likely to be impressed.
If you set higher expectations, people are more likely to be underwhelmed.
I have the same problem. It's a numbers game. You just have to interview at 8-12 places until either a.) you find people who understand you or b.) you find a company with lax hiring processes.
Here's a review of my 2013 job search (all rejections): https://matt.sh/searching-2013
It sounds like you're trying out for more senior development positions. You're not being dismissed out of hand, but they are relying on the white-boarding.
I am guessing by the way you worded your question that you are being at least slightly dismissive of the embedded market. Many people are, but almost everything you touch has a microprocessor that likely is running some C and/or C++ code on it now.
Every cable box usually is C/C++, every DVR, home theater receivers, microwaves, conventional ovens, garage door controllers, hell even that stupid sink faucet you touch to turn on/off is likely running some C code. It is everywhere because it is the one language that is the most transportable and powerful across domains that carries the least amount of baggage with it.
C++ is less likely to be found on the tiny to small chips running things, but you see it more and more where chips can support it. Not to mention, every time you use your cell phone you are using dozens of components, most all written in C/C++ and not all are embedded systems.
Android/Linux is mostly C. Google Search-C++. Web browsers-C++. Java VM is a c++ program. Games-C++.
The only place Java/Ruby/Python/etc has a foot hold is in websites providing crap gimmics that are just wrappers over C/C++ programs. Like uploading a photo or tweet, just providing some glue over all the C/C++ programs that actually do the work.
ATMs , OS development , cellular networks , lots of industry specific desktop applications for petroleum industry , Cutting machine softwares (lathes , cnc etc) are written in cpp .
The core of the project is C++, along with lots of Lua.
1. If you have no prior political experience (e.g., you've never been a governor, U.S. senator, mayor of a major city, etc.), you probably won't get elected unless you're wealthy enough to be able to spend $100 million of your own money on your campaign.
2. If you're less than 35 years old, or were not born a U.S. citizen, you have a zero probability of being elected president since you don't meet the constitutional requirements to hold the office.
3. If you come from certain ethnic or religious groups, your probability of being elected are greatly diminished. The U.S. has only had one Catholic president (JFK), and no Jewish or Muslim or atheist presidents.
4. If you're not good at public speaking and TV appearances, you'll never be elected president.
I expect that my own probability of being the next president is zero, but my probability of winning a lottery (if I ever buy a ticket) is some very small positive number.
>Youre 25 times more likely to become the next president of the United States, assuming the entire U.S. population had an equal shot at the presidency, than you are to win Powerball, says Miecznikowski.
What he's saying is clearly nonsensical because the population of the US is close enough to 292 million to round off and say the chances of you winning powerball and becoming president (if everyone has the same shot) are equally likely.
You can say that only half the population is old enough and you can take off a few percentage points for foreign born citizens, but that gets you to 2-3 times, not 25. Plus he specifically said the entire US population. Not only those qualified. Very odd statement.
I'll take my chances with the lotto.
No matter which shorthand you use, the conclusion is still the same: you're going to lose money playing the lottery.
There's tons of discussion about it.
I will say I stay away from companies that want you to do an extensive try out before there's an offer in place. I had a consulting gig that was like 20 hours of work to "see how I solved problems" I politely declined and told them I couldn't do it without a consulting fee.
Also stay away from any jobs posted on HireArt, their whole process is to have you do a massive "try out" before you even get through the recruiter to the company. Terrible process, massive waste of time.
Good luck in your search!
Disclaimer: I'm a Canadian working in the UK (after working for a bit in Canada).
-0.335386489547 startup -0.331723905544 2015 -0.321593118669 app -0.306937335575 your -0.305739531214 how to -0.275438550569 this -0.261565592652 business -0.252649164518 product -0.250614203448 mobile -0.236041160710 marketing -0.227196421746 top -0.208139598304 with -0.206031814574 5 -0.203087091676 ios -0.202457032685 design -0.201021718651 watch -0.200267475193 startups -0.197466134506 ask -0.196357335391 or -0.192562683469 10 -0.191253124976 best -0.190867070325 ask hn -0.187721441778 cloud -0.187394374070 android -0.186461809237 smart -0.184024063073 you -0.183827664018 tips -0.182653896122 growth -0.181372850037 for -0.178198606780 could -0.162472422631 blog -0.162207059285 java -0.160644447613 development -0.159487418681 social -0.157294135483 should -0.156980003088 bitcoin -0.150609220130 iphone -0.148979317953 tech -0.148345714371 testing -0.147454333035 change -0.145491827860 list -0.145485290331 to -0.144015642286 3 -0.143708682318 robot -0.142186986230 tools -0.140812013948 twitter -0.140696100278 rails -0.140548788801 software -0.138527298008 future -0.138172121531 good -0.138015521103 internet -0.137281744329 facebook -0.136342150691 security -0.134144777413 content -0.133091842596 awesome -0.133049592053 angularjs -0.133019163138 create -0.131147662198 meet -0.128568740027 live -0.125766592272 wordpress -0.125681496867 star -0.125433963958 here's -0.124980970020 test -0.123513256155 day -0.123227292738 podcast -0.123085547655 feedback -0.122558159240 uber -0.122365526765 bill -0.121846476127 things -0.121766619177 online -0.121674711692 entrepreneurs -0.121271063379 vr -0.120835224059 devops -0.120704156113 website -0.120668008266 resources -0.119873591378 tutorial -0.119600975052 6 -0.119263351612 most -0.118987167145 api -0.118767754130 apps -0.118683692890 digital -0.116745925093 will -0.116477896000 data -0.116317401689 needs -0.116223838757 need -0.115050697065 market -0.114878154258 3d -0.114105916526 more -0.111918004178 help -0.111764422735 apple -0.111326594562 new -0.110914386417 year -0.110475338587 customer -0.109564041456 technology -0.109468606136 iot -0.109381535069 application -0.109146062602 4 -0.108483540034 solution -0.108171407112 music -0.107249340464 drone
Lisp and specifically Racket because:
1. It's a community that is strongly oriented toward meeting the needs of students.
2. It's documentation is top notch.
3. It's a single download with no external dependencies. There's even a pretty good IDE (that even has a fairly compatible Emacs mode).
4. Racket in the large is an ecosystem that has tools for many many aspects of computer science that a student even at the graduate level might want to play with [meta-programming, objects, type systems, logic programming, ffi, Algol 60, web systems, etc.]. And it all comes down in one package and there's no futzing around with package managers unless you want something that you probably don't want for a long while...did I mention it's a single download.
5. It's beginner friendly. It has its own textbook. It has a gradient of languages with increasing complexity.
I've got nothing against Haskell or Go or anything else. And for a person in a different situation I might be high on one of them...or Erlang. But the orientation of their communities is different and so the problems that they're good at is different, i.e. Go solves Google's problem of hiring a lot of people with a C++ background for systems programming and the problem of packaging programs that run on more servers than one can deploy reasonably to in a week [it uses native executable binaries].
Lisp & Algol-like has the difference where Lisp's code is also data and its code can rearrange code using macros written in Lisp itself. Both can have functional programming inspired constructs like `map` and `fold` as functions.
Haskell is different because all its code is lazy. So if you write `take 1 (map ((*) 2) [1..1000000000000])`, it runs instantly even though writing idiomatic lisp or python or C will have the computer spinning for ages going through all those numbers you don't even use. It also has partial application of functions, as well as pure functional programming by preventing you to write a line that doesn't contribute to the returned value. The sophisticated type system I have not ever seen outside of the ML family of languages, either.
I haven't read the Dragon Book, but I've written some compilers in my free time, and my compiler code was much better after I had a go at Haskell.
It us Scheme (a kind of Lisp), it is very functional focused, so many concept will translate fairly good with Haskell and along the way it teach you the fundamental of an interpreter, which is not quite a compiler, but still matching what you are interested in.
And you will be a better coder after that book, I guarantee :)
As for the choice of a functional language for a beginner, I think you just should pick whatever has better introductory materials available. You're likely to experience a big mental shift by using a functional language for the first time. It was a struggle for me, at least. That being said, I'd recommend a Lisp derivative - Racket. It has a very nice tutorial and a good IDE. Also, John Carmack's son game in Racket: https://news.ycombinator.com/item?id=10111479
Deciding whether to learn a language or learn how to write a compiler is more difficult. If you are struggling with the Dragon book, have you condidered "Modern Compiler Implementation in ML"? Although ML is even more niche than Haskell, it is a functional language and the book takes you step-by-step through the process of writing a compiler for (a subset of) it.
There seems to be a certain personality associated with lisp programmers, which emanates when they speak about the language. So logically I was pretty confident in my choice from day 0. However it wasn't until I actually made a program with it that I was emotionally confident and content with the choice.
In conclusion, I recommend you build a program with Haskell, Lisp, and/or an idea from the dragon book. That experience may give you the best idea of what path will be the most rewarding.
For instance, saying a program "has a bug", is a completely misleading statement. No programs have bugs. It is impossible for a program to have a bug, just as it is impossible for a physical process to "do something wrong". Programs do what they do, just as molecular processes do what they do. The concept of error and meaning does not exist in a program, just as it does not exist in the physical universe. Meaning (and errors and bugs are a kind of meaning) are things outside programs and outside physics. When a program "has a bug" it means the programmer screwed up, not the program. A program cannot produce errors, because programs, and computer systems in general, do not have the capacity to have meaning. This is what Searle is demonstrating with his argument.
This is true for all the popular computational approaches we have today. However, because the human brain appears to function in a purely physical way, and computers function in a purely physical way, it should be theoretically possible to create a computer system that is conscious and aware of meaning just as we are. You refer to this as "Strong AI". Other refer to it as Artificial General Intelligence. I refer to this as machine consciousness. To solve the machine consciousness problem means understanding how awareness, meaning, and representation in general, works. Then building a computer system that engages in representation and instantiates awareness.
If an actual person were put into Searle's box, the person would learn chinese. Also, the person could 'intentionally' produce incorrect answers annoying the "programmers" who set the box up in the first place. But a modern computer system cannot 'intentionally' produce errors. it's completely non-sensical to talk about computers as having intention at all. programmers have intention, not computers.
Solving the intentionality problem is the other leg of machine consciousness. Elon Musk, Steven Hawking, Nick Bostrom and others make arguments about the dangers of an AI (of any variety) which may acquire intentionality and representational ability, while ignoring the actual deep problems embedded in acquiring those abilities.
Awareness, representation, and intention are so fundamental to experience that we have a very difficult time understanding when they happen and when they do not. We see a representational world all around us, but very explicitly, there are no representations at all in the physical world.
I believe machine consciousness is possible, but none of the existing approaches will get us there. Searle's chinese room is one succinct argument as to why.
The approach I am taking is a kind of metabolic computing. Where single function processes interact in some way similar to molecular interactions and those processes are developed to produce, computational structures like membranes and DNA and eventually "cells". These cells then form multi-cellular structures. These multi-cellular structures and underlying "molecular" interactions instantiate representations and representational processes, like a nervous system. A computational nervous system which embodies representation, intention, sensation, action, imagination, and because it engages in representation making, would be aware.
I would love to hear someone describe how any kind of computational approach can produce meaning inside a computer system. We produce meaning and representations so easily; it's hard to understand the difference of perspective necessary to see how representations must form. If someone has an easier approach than the one I am taking, I would be very interested in seeing how they solve the problems of meaning and intention with code.
Whether or not we say "machines can think" is a political question, and political power comes out of the barrel of a gun. If a machine can wield political power, then it can get you to say "machines can think" because truth is inherently political.
Pre-Cancer screening (Gates & Bezos invested)http://www.grailbio.com/?ref=producthunt
Here's a better article from the MIT reviewhttp://www.technologyreview.com/news/545326/illuminas-bid-to...
The place to start irrespective of having pancreatic cancer or not is with a living will and an advanced health directive. Even if you're going to freeze your head, you'll likely benefit.
Perhaps there are organizations or treatments that you will learn about.
Also, this PBS series on cancer was informative: http://www.pbs.org/show/story-cancer-emperor-all-maladies/
Think it might be on Netflix. It's based on a best-selling book: