There's no declaration of what attribute should be used for considering distinct users. After guessing it gave a hint to the effect of "there are duplicate Given Name values". This is rather counter intuitive since many people share a given name.
739 karma · joined July 7, 2009
There's no declaration of what attribute should be used for considering distinct users. After guessing it gave a hint to the effect of "there are duplicate Given Name values". This is rather counter intuitive since many people share a given name.
One of the interesting parts about building the outage related challenges is ensuring not just that they break, but that they break in a consistent and reliable manner. Also, that they don't interfere with your candidate's ability to work on the host.
Through contracting I make about 30% less than I did as a salaried employee, but I am immensely happier than when I was employed full time. Even if I wasn't bootstrapping a business, that tradeoff feels worthwhile to me.
I’m the creator of Opterview. It’s a CoderPad like experience for interviewing DevOps Engineers with challenges for screening your candidates. You get a shared terminal in the browser connected to a dedicated host configured for the challenge you choose. Some example challenges include:
* Debugging a web application that’s experiencing an outage
* Diagnosing issues on a misconfigured Docker host
* Writing configuration management code to deploy a web server
* Using Terraform to provision resources in a dedicated AWS account
Opterview has been in a private beta since this spring, and last week I finally opened it up to everyone. I’m a solo founder, and Opterview is at this point fully bootstrapped. If you have any questions I’m happy to answer them!
So it's not bad per say, but it's not valuable at all. Even though it's being sold to you as such.
And exercise itself has a major influence on T levels.
I could imagine search with some standards (commit message format, branch/rebase strategies, requiring an associated tickets) would be really effective, though not so much the general case. Hope you can share in a follow up post if you find ways to deal work around these problems.
But number of commits is a horrible way to infer seniority. Unless you value "frequency of checkpointing changes" above all else. You get what you measure, so I suspect OP is going to get a lot of small commits in the future.
So it's not the case that there was a huge cache of information that he didn't have access too until entering office. It could have been the case that there were some details that weren't made available to him, but that seems unlikely to amount to anything that would lead to a complete reversal of policy.
At least, I speak for all developers that have used it.
You really have no way of knowing if you're underqualified or not from the amount of information about any particular job you might come across (on a job board or a company's website). Now obviously they may list a bunch of technologies you've never worked for, but even then they might be willing to let a smart person learn.
I stopped reading after that line.
Right now on the candidate side of things it's pretty much the same situation. Go through job listings, send resumes to any that sound interesting, do about 4 phone interviews a week, pass on roughly 3 of them because they either aren't working on something I find interesting, the position itself isn't something I'd enjoy, or my gut tells me to walk away due to the impression I got from the person I talked to. I will pay you to not have to deal with this.
I get that for most companies that are developing software it is to support some other profit center and not their primary focus. They hire subpar engineers because that's all they really need (and they're not compitent enough to tell the difference), so a lack of automation in this context, especially test automation, is not surprising to me in the least.
But the idea that you would have a software based profit center that isn't automatically tested, especially with the competitive nature of the web requiring rapid turn around on features, absolutely blows my mind. Are people firing from the hip and hoping nothing breaks or clicking every link on your site? In which case you're either way too overconfident in your own abilities or have no value for your own time.
Kudos for acknowledging the benefits of their approaches, but I feel like it's the architect's responsibility to reconize the most cost effective solution for the context at hand. How many problems aren't we hearing about that could have been solved with a new network switch instead received an application rewrite with an SOA architecture?