Ask HN: Hiring managers, what tech skills will you be hiring for in 2017?
This should help folks trying to get into your company/industry on what they need to know and conversely help you in finding a better pool of candidates.
This should help folks trying to get into your company/industry on what they need to know and conversely help you in finding a better pool of candidates.
I look to hire people who just need a job. People who are qualified, but not overly qualified. People I know will depend on the job for a long time, but not looking to make it their lives. Hard workers - getting there on time, but also leaving at the stroke of 5. Ivy league schools are a red flag. Huge resumes are a red flag. These people will constantly question whether every decision is optimal, prod incessantly at company strategy, continuously try to impress, and are always hungry for praise, recognition, and "interesting work." When they get bored after 6 months, they quit and go somewhere else (remember they can easily do so because of their pedigrees), often to a competitor, bringing company secrets with them.
I need someone loyal, who knows how to take orders without question, and is prepared to do the work that needs to be done day in and day out because they want the paycheck. Reading the above, you might think I'm a terribly demanding boss, but using this hiring strategy has produced a 100% employee retention rate and by all accounts we are all quite happy.
"a reliable person who can actually, really, like, totally for real drive a problem to resolution and then go spend time with family. if there's an emergency, they pick up their phone and try to help."
this is a small percentage of the population, but big enough. it's why we (based in california) have a 75% remote workforce. hint: we still pay california $. that's how you retain talent. everyone on my team lives in huge houses and i live in an apartment.
you'd (well maybe not you, but you know what i mean) be surprised at the number of super-intelligent ("smart") people who can't solve problems when the pressure is on.
My job entails emergencies from time to time, and it's rewarding to solve an issue at the customer, before it gets out of hand, while still solving problem on the long-term roadmap during the day.
What I do regret is the complete lack of remote, meaning I will pretty much leave this job soon, as my fiancée is currently living on the other side of the planet.
It's great to see companies that do care for employees well-being in other ways than office perks, and I'd love to see more of that in the future. Are you still looking for applicants?
i don't recruit on hn. i will say this though: most people like you, if given the opportunity to work for a smaller, unknown firm for less money remotely, and a larger well known 'famous' firm for more money on-site, they will usually choose the latter even if they really want to work remotely.
in other words, "i want to work remotely" usually really means, "i wish i had all the upsides of BigCo with none of the downsides."
I can't blame you on that one.
Still, I want to address something. Remote work is a different paradigm, it doesn't make a lot of sense to compare the two of them. The upsides are pretty different, and so are the downsides.
I'm sure some people do not realise it requires a wildly different skill set, as well as a different mindset, to work remotely. The first thing that comes to mind is communication, the next is processes, and that's not the end of the list.
I'd take the job getting me closer to my loved ones any day over a job at BigCo personally, especially considering I feel strongly about the upsides. To each his own, I guess.
Are you willing to share any communities or other resources you do use for recruiting? No pressure at all here, just curious.
(Not always successfully -- I have to admit -- but I try).
I've seen a couple of such shitstorms where we had to hack on production systems to get them back to work quickly before thoroughly fixing the actual problem. Almost always, it could have been prevented with proper unit testing, code reviewing and more thought-out deployment processes.
1) Anything that can be effectively described as "blue collar" will probably be replaced by automation within 3-10 years depending on the job. 2) Creative thinkers should be valued more highly in the tech field than those that can just follow orders blindly. Very few tech fields emulate an assembly line and the ability to think for yourself and develop an alternative solution is and should be highly valued. 3) Most people in the tech field, both employees and employers, are probably intellectual to a degree and free thinkers in and of themselves. So the cycle continues.
I'd also like to point out that this idea of a blue collar work ethic is somewhat flawed. There is not specific work ethic associated with the blue collar worker naturally; it's just a result of never having enough money for pleasure, so work becomes a part of the routine. The job doesn't matter as much when you're dirt poor as long as it's making money, and the risk of job loss is what you're describing as loyalty. This is really nothing more than a capitalist machine at its worst, not some utopic worker's attitude we should all aspire to.
A lot of management hates this. Less skilled managers, just want a dev shop where they can build and assemble parts.
I wouldn't work for this guy, I want to work with people who are smarter than me and from whom I can learn new things. That said, he's right to not want someone like me, I get bored pretty quickly when I'm the smartest guy in the room so I try like hell to avoid that situation. But to each their own of course.
How would is such a person define success for themselves, and how does your prescribed plan achieve that?
In other words, are you prescribing a plan that is beneficial for the company, but bad long-term for the employee, because they didn't grow enough by not 'devoting their life to their job'?
I get this.
100% owner also means they bootstrapped and were a solo founder.
By the way 7 figures covers everything from 1,000,000 to 9,000,000 - so I read it as being barely seven figures in profit, or I would accept if the actual bottom line profit were 700k-1M (so that it's a bit of an exaggeration to call it all "profit"). However the top line (sales) has to be (well) over 1m or I am unhappy/consider it too much embellishment.
OP - what does the top line look like? Roughly how many employees do you have?
The best advice to take from your post is to make sure you know which type of company you're applying to. A small bootstrapped lifestyle business probably won't hire like a hot SV funded startup, which makes a lot of sense.
I thought you had 100% retention rate?
Those who left were hired at an earlier time when I thought hiring the top tier Ivy Leaguers was the way to go.
I understand your reasoning when it comes to well defined business requirements with well defined technical problems. But once the initial set of requirements are done, how do you proceed? I suspect you need at least some amount of overachievers to fill mid-level management roles.
Technical managers have to be sensitive to new information, * especially * when it ruins their spec.
What he wants is stability. You'd be surprised how many very smart people put a premium on that sort of thing, especially when they get older.
An employee with limited options = A more stable employee
NYC isn't exactly a place where you have limited options. You want limited options? Try to find a job upstate.
From perspective the employee it isn't stable. Sounds like he'd get rid of you, if you disagree with anything.
- Questions... people need to ask questions (but not ad nauseam).
- Compensation... 'need a job' should not translate to a desperate wage
Understanding and acknowledging your employees have a life after work is important. The only question I have is how, or do you give out bonuses from your yearly profits.
Basically you've described my serious, competent, self disciplined ex-mil and reserves/NG coworkers. Wait... do I work for you?
Perhaps the takeaway for all of us is that we all need to be humble and at least pretend we need our jobs, even if we're aggressively saving for an early retirement.
As such, I tend to hire those who don't take oneself too seriously. The OP's redflags I feel are corollary to this observation.
Be humble and get shit done.
Your hiring strategy is not "your" hiring strategy: its every mindless, exploitative, and compassionless corporation in the universe. In otherwords, youre overwhelmingly average! Youre contributing to the very problem youre having: no one wants to work for an entity that operates like this.
[0] https://hbr.org/2011/02/hire-for-attitude-train-for-sk
[1] https://www.eremedia.com/ere/hiring-for-both-attitude-and-ap...
• ability to assess tech/architecture risks in apps
• experience in devops automation ("secdevops" if you will)
• proven skill in communication regardless of depth
The ideal candidate would have all three, but I could settle with any two of these and still be happy.
I am not currently hiring, but I'll gladly keep any CVs I receive and prioritize follow-ups with anyone who reaches out to me directly. Austin/DC for curious souls.
---
p.s. the web appsec space is in ludicrous demand. If you've got a breaker mindset, you'll probably come out ahead if you read up on it. If you're a developer right now and want to dip into it, I'd suggest: https://www.amazon.com/Web-Application-Hackers-Handbook-Expl...
Trust me, us security folk will thank you. Heck I'd suggest it to non-hackery devs too. It's a good way to find out how us security types see the world.
What if I am infosec/netsec/whatever student and I watch a ton of Pluralsight on AWS and Docker and I am starting to build my own lab. Will people hire someone like me? I ask publicly because I assume I'm not the only one.
About that... you know what's more likely to get you hired in the space? If you have no work experience in appsec but walk in and tell or show me a pattern for how you automated appsec testing in a build pipeline or QA process at home and describe the challenges you had to overcome, or if you have a few fleshed-out bug bounty submissions (with exploits) and can describe your favorite one in depth, or if you've taught yourself how to review code for flaws and could do it in front of me in an interview setting, I might be quite willing to waive the years in appsec requirement. Other smart hiring managers probably will too.
https://www.owasp.org/index.php/Category:OWASP_WebGoat_Proje... <<This is a good starting point for learning how to break things. Also for learning how to fix them :)
If you already have that experience but not specifically in security, it'd be a great fit and you'd be encouraged to apply wherever automation is even barely touched on as a requirement.
Guarantee you any appsec hiring manager will consider that background.
I'm a senior developer and I made a name for myself when we started having the requirement. I helped secure ~10 webapps as I was the most knowledgeable about security amongst the devs.
The app sec guys I know at my company, though intelligent, are not strong developers. There were times I spun a story to get them to mark something as false positive - or I knew what the scan flagged for and coded around it. I know, bad practice, but sometimes the scanners mark something as critical when IMHO it's not.
Once our apps were secure, maintenance is pretty low as we'd just fix any new vulnerabilities introduced by coding, or updated by the scanner tools.
Do you see a need for strong developers in app sec world? If so, any recommendations on ways to make the leap? Not really looking for something where I just click a button and scan...but something more in depth that would use my development experience. I have a Security+ cert, doubt I can get a CISSP since I don't know anyone with it to get sponsored.
As for strong developers in the appsec world, certainly. Especially if you have a strength in the automation side, you can easily carve a niche out for yourself. The main two areas where I can see a dev taking charge are in driving the use of security features in frameworks product teams already use (this is a HUGE bullet being pushed by notables in AppSec as it reduces the effort involved in uptake of secure coding practices) as well as in leading automation of new tooling in support of new frameworks. There's also the angle of developing custom solutions to address firm-specific problems, something appsec people without a strict development background will have a hard time doing.
Quite a few appsec leads prefer bringing in developers with a breaker mindset in as appsec hires, so yes, there's always room. Depending on how you answer the question "what does 'secure ~10 webapps' mean?", you can probably easily score a lateral move into AppSec (Senior Dev -> Senior Security Engineer or Senior AppSec Consultant/Engineer).
My keybase profile has all my contact info if you want more tailored guidance. Even if you don't join my firm or any of the other firms I have a hand in shepherding, we desperately need more people in appsec, so I'm all about sharing this knowledge.
I'm a tech lead who's always been interested in appsec(very passively), but it always seemed like a long journey from here to there. And I was under the impression the rates were pretty similar which made the task seem more daunting.
I can share more detail in private eg on twitter.
If you can sit back and pick and choose like this, then how does that square with the mythical "shortage of engineers" everyone complains about?
Not sure about the 95%. Maybe that's people who can do it without bugs nor expressing that this is a very dumb question unworthy of them xD
What I do see and hear about are people that simply do not know how to program. FizzBuzz generally cuts out 50% or something out of the pool right? So that's 200 of those 400 resumes out the window already.
If you can't pass FizzBuzz then I think it's safe to call you incompetent, right? From the POV of paying you to code, obviously.
At least in Berlin there's a lot of competition for "talent" (perhaps we should call them skilled developers rather) and if one can already cut the number of applicants in half before even defining the job description... well then it's not hard to see how there might be a shortage.
However I think if you're looking for entry level developers there are way more options.
I think it's fair to want someone who's experienced or at least has a fair bit of knowledge in either Angular/Ember/React if you're looking for a web dev. The companies I talked to were at least reasonable enough to know that general knowledge transcends whatever's the current hot framework.
American companies front-end static pickiness for rando applicants. A snapshot a month ago by a non-technical HR associate indicates the ideal applicant would be experienced with the following list of 25 emacs extensions, prefer while loops over until loops, have memorized everything in Knuth but use none of it on the job, and wear a size 10.5 shoe preferably eee width.
The real world dynamic work experience over the past couple decades is someone comes to with some sob story about "one of our execs went golfing with one of their execs and I know you've never used freetds or mssql but you need it up and running and integrated with out stuff by the end of the week" "what is it?" "I don't know but just get it connected as best you can". Another classic was being on rotating pager duty and getting midnight calls about a product I literally did not know existed, I mean I'm used to handling problems with no training or documentation, that's to be expected, but I didn't even know we were selling this thing. Both stories are true and honestly not very surprising. This is pretty much how "real world" IT works AFTER you're hired. And I'm extremely good at that, its like a giant self solved puzzle, so I don't mind, but I assure you, no one interviews rando applicants for that, even though its the most important part of keeping the job.
Mostly I get work from old coworkers and the first month is just like six months of normal change rate rolled into one, its not really a big deal. Its a forklift upgrade. I've worked thru several of those, a new job is just a forklift upgrade along with a new chair. I could walk into any dev job on the planet and be productive in a month and stay productive there as long as I want. I know three people that experienced up front picky because I got my current gig because I know some folks and HR had to go thru the motions, so they sat thru insane tier interviews that I skipped. Hours of HR style "You reach down and flip the tortoise over on its back, Leon." and it goes on and on.
I briefly ran hiring for a team with a core skillset that I thought was pretty general (python/web), but a lot of the python resumes I got turned out to be 'I used it in college', 'haven't used it recently', or django-focused devs who were uncomfortable with anything non-django.
I'm not sure what that means other than that I'm bad at sourcing. Seems like 'aiming at my stack' was the wrong way into this, but I'm not sure how else to filter resumes.
Aside from the obvious interest in building container orchestration systems, I look for a passion to solve real user problems, not only building a piece of tech.
Bonus points for knowing about Docker or containers or clouds or Golang or security.
More points for meeting users where they are. And the most bonus points for leadership and initiative.
We're particularly looking for someone to lead and/or manage our software eng team building security features into Kubernetes and GKE.
Apply and make your dream come true!
Bear in mind that our hiring process is SLOW, so be prepared for it to take a lot of time. Best of luck!
Also worked as a TE @ MS - had to meet devs & c level execs in startups.
Every time I've applied to Google Canada, I've been told that I'm too late (I get notifications when the jobs are posted and apply asap) and to apply 6 months later or that I'd have to move to SF (really want to work from Canada).
It's my dream to work at Google.
Also backend and data engineering roles (C++/Java/Go/Kafka/etc) are in high demand here.
SoundHound is hiring in SF/Santa Clara/Toronto.
Sidetone: I am semi-actively looking for a Javascript Engineer job (fullStack or frontend with ~2 yr exp). Are y'all hiring?
Can you explain what is your product? Not 100% sure I understand.
I think they relied on user submissions for that functionality, but if it works it works.
I've since switched to a personal policy of "no Google stuff on my phone", which means not having access to the Play Store. I haven't checked lately to see if SoundHound is on Amazon's app store (it wasn't when I first checked, but neither were Spotify or TuneIn and now they're both available, so I might go do that).
What do you look for in a resume or application that would make you confident that you've found somebody with that experience?
1. Core JavaScript. You should be able to read modern idiomatic JS code pulled from an open source project and explain what it is doing and how you would modify it to add features.
2. Core CSS. You should be able to review Bootstrap source and explain how it works. You should be able to create static HTML/CSS to match UI mockups.
3. Higher level SPA library/framework (e.g. React, Angular, etc). You should be able to demonstrate an understanding of the core concepts of your chosen framework.
I find that these 3 skills are sufficient for productivity in SPA web development.
It's not so much specific tech skills as attitude. We're strong on pragmatism with a touch of pride in doing it right. Pragmatism without that pride in quality leads to hacks that are unmaintainable - obsession over perfect without pragmatism leads to never delivering.
This website seems to be mostly Californians. (Maybe I need to hang out on Whirlpool more.) Is it worse here or better?
This usually entails hanging around at tech conferences, meetups, user groups, and other such in-person social networking events, including more business-focused ones. Do things to contribute, and talk to people. You'll want to focus on smaller companies without a lot of strict hiring requirements. There are decent companies out there willing to hire junior people without a lot of formal experience. Flip side is that agencies also evaluate the companies for you before you even know anything happened. You won't have this, so you'll have to be more careful about checking out any company you might work for. You probably won't find your dream job right off the bat, just find somewhere you can build something with actual users, make some money, and learn things, and start building a resume. You might luck out and end up somewhere awesome, or you might find yourself somewhere you just want to get enough experience at before moving on.
also, make sure your portfolio site is up to date and has lots of projects that you're working on.
If you've got no commercial experience I wouldn't really recommend going to an agency, mostly because agencies are too expensive for companies if you're just going to hire juniors - plus there's usually no shortage of junior devs, especially this time of year.
Bonus points for recognizing the bullshit parade that is the current startup world. e.g.: NodeJS has value, but it's mostly the same wheel we've had for 20+ years. Or that MongoDB's changelog has consisted of standard SQL features for the past five years and that pgsql would have been just fine (had people read some boyce-codd anyhow).
Funny, because it's pgsql that added a JSON data type in response to MongoDB and others.
* It has a revolutionary module system (Common JS) witch allows less coupling, more code reuse and better abstractions.
Try building something with SDL on Windows if you want to see this for yourself.
And modules in NodeJS are truly modular as they contain all their dependencies, even libraries.
The latter: as mentioned in my previous post, this is, to me, a misfeature. Transitive dependencies being encapsulated in a dependency increases the likelihood that those dependencies don't get fixed when bugs inevitably arise in those transitive dependencies. Do not want.
Since all variables are private (function) scoped in JS you do not have to worry about shadowing (overwriting variables), especially when your functions don't have any outside couplings, witch is possible with (common JS) NodeJS modules as modules can be required from within functions or methods. They are just like any variable.
I think I'll have to make a blog post to explain it in more detail. And I encourage you to do the same ...
What do you mean by transitive dependencies ? I don't think there's a concept of transitive dependencies in NodeJS.
If you spend one hour to fix a bug in a open source project, you have probably saved other people thousands of hours of work, money, or frustration. Software is special as it cost very little to copy code, so your one hour contribution can be copied many times creating a lot of value. It's like you would bake one cake once and it could be eaten many times, over and over again.
Alright, I get you now. I agree with you on this that it does allow for that sort of encapsulation--but, IMO, that's a bad kind of encapsulation; having to put fundamentally object-oriented data outside of the object strikes me as a profound routing around serious linguistic damage.
> Since all variables are private (function) scoped in JS you do not have to worry about shadowing (overwriting variables), especially when your functions don't have any outside couplings, witch is possible with (common JS) NodeJS modules as modules can be required from within functions or methods. They are just like any variable.
This, OTOH, is pretty much the same as any language with any kind of encapsulation. Maybe ES modules have finally approached parity, but it's nothing special.
> What do you mean by transitive dependencies ? I don't think there's a concept of transitive dependencies in NodeJS.
Every dependency of your dependency is transitive. Just go look in the node_modules directory of any of your dependencies! If you require X and it requires Y and Z, bugs in its version of Y or Z are suddenly your problem. And its upgrade strategy becomes your problem, too.
OTOH, in something like Maven, saying "no, use my version of this transitive dependency" is very straightforward.
> If you spend one hour to fix a bug in a open source project, you have probably saved other people thousands of hours of work, money, or frustration.
And my client doesn't care. If I'm working on my stuff, sure, I'll do that if it's the most efficient way to solve my problems. My clients do not give a single shit about this, though, and I have to build things they can deal with, not me.
So this is at best a misfeature. Primarily a bug.
function takeScreenshot(webUrl) {
var webshot = require('webshot');
...
}
function visualDiff(imgPath1, imgPath2) {
var imageDiff = require('image-diff');
...
}Take for example, Walmart Labs move to Node.JS + React [1]. The rationale is quite obvious here. It's a step to distance from the corporate portrayal of "Walmart" and create an image of a nimble, developer-friendly team (There maybe other important reasons, but I'd assume good PR mattered a lot). Contrary to what HN may suggest, the first thing that exhilarates a developer (the early ones to say the least) isn't the business, it's the tech.
[1]: https://blog.hellojs.org/walmart-labs-releases-electrode-mov...
So when I see a job posting advertising those I know the people in charge have no clue in what they're doing and treat developers as janitors.
Or as pg said: "The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those."
don't forget the tennis courts
I've definitely had people that interviewed well that just wanted JIRA tickets fed to them immediately upon starting. It's very hard to figure out if someone will seek out and make improvements consistently from the basis of conversations.
(I'm in ops so there's rarely a body of code available they can share for how they work, either.)
I mean, what ambitious person would like to worse in less that best job available on the market, for best possible money?
Here is the description for our Backend Engineering role, a really cool new role that we're hiring the first of onto our Platform Team to compliment our Full-stack engineering team: https://jobs.lever.co/lever/7ab138b0-b5c8-425d-93ae-2fc2b051...
This shows up in a resume in lots of different ways. For some people it is a rich Github profile. For others it is that they paid their way through college by building websites or apps.
We primarily hire Ruby on Rails developers who work remotely. Seeing in someone's Github profile that they like to contribute to open source and know how to collaborate with other developers are really important.
Our stack is node.js/React/Postgres so knowing any/all of those is a bonus, but we don't specifically target those skills – we instead look for a diverse, intelligent set of engineers who have a strong technical background or a newer technical background but heavy experience in a non-programming field (mathematics, economics, architecture, teaching, customer support, etc; they all have their benefits). Interest in being "full stack", participating heavily in the product management process (strong opinions loosely held!), and a belief in the critical importance of design & UX (unfortunately still heavily undervalued in the Enterprise space...) are important.
Hiring in San Francisco & Washington, DC by the way.
troy.goode@lanetix.com
This might explain why companies want H1Bs so much. Places like India and others tend to produce very pliable candidates who will just take orders and execute. I think this is a much bigger factor than wages.
Yikes. Can't help but think that you really just want a robot.
For 2017, I want to hire more engineers with Kubernetes, CoreOS, and Go experience. My team has deep Linux systems administration experience but we've automated ourselves out of most of the day-to-day admin work of yesteryear. Our future hires will be heavily focused on automation. We've already automated builds, testing, deployment, monitoring, and metrics in a Kube/Docker pipeline. I expect to automate load balancing and hardware deployment in 2017. I also expect that we will adapt many of our non-Kubernetes data services for running containerized in Kube.
Interviews have practicals where you work on problems you'll see regularly with skills we expect you to have (like writing code, debugging, and task breakdown). Good communication, pairing skills, quick learning, and taking responsibility for your circumstances stand out.
Advice for senior engineers: brush up your practical programming. If you've been in an architect/leadership role, you may be rusty. Make sure you're comfortable on both whiteboard and keyboard.
If you spent the last 5 years writing iPhone apps, we expect you to know iPhone development pretty well. Memory management is the obvious area here.
Be ready to explain the most recent projects on your resume. Think outside the box - if you wrote code to process messages from a black box, how do you think the black box worked? If you consumed JSON messages, how much can you explain of JSON and JSON parsers? Many projects are so narrow in scope that we can't have a meaningful conversation about them, so be prepared to broaden into adjacent areas.
Advice for new grads and early-career engineers: have some solid, non-trivial code on github (or equivalent) and make sure we know about it. Be prepared to discuss it and explain design decisions. Few do this.
This post is my take on the question - what follows is especially subjective and not representative of shopkick:
Don't put stuff on your resume that you don't know. Or, brush up the skills featured on your resume.
Learn a scripting language, especially if you're a server engineer. People who only know Java/C++ are at a big disadvantage if they have to write code in an interview. How big? Turning a 5 minute question into 35 minutes is typical - and it gets worse. One very smart, very experienced man took 45 minutes on such a question. Of course, don't just port Java idioms to Python; learn Python idioms. Good languages are Python/Ruby/Perl. I think a HN reader probably doesn't need to be told this, but just in case. Properly used, scripting languages teach techniques which carry over to compiled languages.
Server engineers should be comfortable with either vi or emacs. And with basic Linux. Personally I find it astounding that a server candidate would be unfamiliar with ls and cat, but it happens.
I hope this is helpful and doesn't sound arrogant.
After I posted my previous response I realized that I actually know a few emacs keybindings thanks to tmux, even though I've never used the editor. I use a lightly modified vim on my laptop, but I think it's best to learn enough of the defaults (of any application/utility) to speed up your workflow on a new host.
+ for new web platform things like Service Workers, advanced SVG.
Could care less about whatever franework is hot this week.
But it is really sad that people mostly hunt for keywords in resume.
We may also need a strong lead for a new business unit, a role akin to 'founder lite' — you run a business unit with two others, you have your own burn rate, your own P&L, etc. The strongest skills someone can have for it are former founder experience (aka: broad experience doing lots of things, moving quickly, MVP, etc).
Palo Alto, San Francisco, Seattle.
Where are you located? This is something I can definitely do.
We are looking for c# devs with some front-end experience and ops people (linux / Windows / networking). Azure / AWS experience is you have it. You can do SQL and have a nice grasp of distributed architectures. Experience with CI is appreciated.
Most of all though, you need to have a passion for the job. Really like what you are doing and be proud of the stuff you create with the team.
As a company we value your efforts and actively encourage you to have a normal family life but we also expect you to handle a shitstorm (with your team) if need be.
We hope to expand our team in early 2016 and have a mainly java micro-services with some PHP and native apps on the front. Will likely add to the java team in addition to an IOS dev.
Nice atmosphere, nice people. We try to select for people who don't like to be micromanaged (but are still friendly) and assign responsibility not tasks wherever able. Varying degrees of success but overall happy with the approach.
Looking for at least one highly skilled person with java experience and ideally a fin-tech background. Not sure the salary would be competitive with SF but cost of living is small and its a great lifestyle (for those who like daily excitement/challenges and learning new cultures). On site. Other roles would likely be unsuitable (read: cheap!) for the HN audience.
- scalable architecture with legacy systems
- tech strategies to enable engineers & product to create success
- broad knowledge of useful serverside languages & technologies
- bringing a multi-platform SAAS to multiple regions
- processes and tech to ensure quality of output
- AWS dev ops
But for the sake of the OP, skills would likely be a nebula of PHP, Go, SQL, node, react, Webdriver, kubernetes and tech related to application infrastructure (Kong, Message queues etc). There are other nascent products which may demand other technologies - a years a long time :)
If any of this catches your eye hit me up for a chat ashleyc@perkbox.co.uk
If you have that, breadth in projects and technology and you are genuinely excited by the opportunity I have on offer then I have found that a good mix.
Since it's a jr role I'm looking more for evidence that they want to learn than examples of accomplishments.
- Developers: We use mostly java, swift, and JS (Angular 2) but we always look for polyglot developers, full stack developers, or whatever you want to call someone that see the language as a mean to achieve a goal and not the goal itself.
- DevOps: Deep ec2 knowledge and experience. AWS certification is a plus
That also holds true in my personal life as what I look for from others and expect of myself.
You can apply here; http://grnh.se/p4tu8l1
I don't have anything to offer in the way of specific tech skills. I simply look for someone that is inquisitive, extracts satisfaction from solving problems in elegant ways, and has a strong motive to better themselves.
These qualities, and a few others, tend to transcend tech stacks and techniques of the week.
My most successful interviews have come through chatting with a candidate in an informal setting, presenting hypothetical situations that were actually challenges we've faced in the past here and there in the conversation.
I dropped the whiteboard and puzzle thing a long time ago and I've never had better engineers.
YMMV
(I do ask to see some code beforehand)
* Ansible
* Python
* Go
* PHP
* Docker
* AWS
* GCP
Experience with the above would be nice. What I actually require though is not specific to a particular technology:
* Not a dick
* Ability to reason
* Ability to iterate
* Ability to communicate at multiple levels of abstraction
Oil and Gas
I was once a Front office dev (Microsoft Stack) for commodity trading house. If you are in USA, Canada, or Japan, I'm interested in learning more about your business.
And we're a consulting company that works with mostly oil and gas companies.
* development services and applications on Kafka and Spark
Since we also do private consulting and project-based work in addition to our workshops, we have recently got to talking with our clients about helping them get full-time employment. So I think this post is pretty timely and very relevant to us. Here are a few reasons why we think React is important for the job market.
Lots of companies are choosing React for their front-end these days. It allows your front-end devs to embrace the full power of JavaScript for the front-end -- no more messing around with jQuery and tons of plugins. Sure, there's a bit of a learning curve, like all new things. But there is now a large and devoted community to React and it's only growing. A personal friend of mine convinced his boss to greenfield their entire app with 10,000 lines of jQuery, and rewrite it entirely in React. He was a new hire (and also a great communicator/salesman).
Coding bootcamps are embracing React as well. Since most of these institutions survive year-to-year based on how well their placement numbers are for graduates, they are paying close attention to the trends in development. One could argue that since they are probably more technical than the average recruiter, they may even have a better grip of the pulse. FullStack Academy, of New York and Chicago, recently wrote a blog on why they're moving their curriculum from Angular to React (https://www.fullstackacademy.com/blog/angular-to-react-fulls...). App Academy (SF & NYC) has had React in its curriculum for a number of months (https://www.appacademy.io/immersive/curriculum). And I've personally spoken with alumni of Hack Reactor in SF who said that most students built their capstone project in React (or attempted to).
Is React the best solution? That's arguable, as all things are. It also depends on what you want to accomplish. But for the relevancy of this post -- asking what tech skills people will be hiring for in 2017 -- I would argue that React is going to be one of the top skills. And with that includes...
Redux Webpack Immutable RxJS
As far as backend, the top three technologies that we've seen with our clients are:
Python Go Docker
But of course, all of this is moot without the foundation of strong JavaScript skills. Our students who have strong JS skills pick up React quickly -- those who don't only get confused.
Anyways, if you are skilled in React and other related technologies and you are looking for work, you can always email me: ben at realworldreact dot com with some info about yourself and/or your resume.
A series of 6 small books that cover the JS fundamentals in detail.
* Comprehensive lesson-based: FreeCodeCamp. An easier, piecemeal option with plenty of hints and guides. Disclosure: My business partner is the CTO of FCC https://www.freecodecamp.com/
* Video: JavaScript30 by Wes Bos. 30 Vanilla JS Challenges. Wes is a fantastic teacher and this is his newest series. I haven't gone through it myself but I've taken his other lessons and been pleased, so I feel somewhat confident in recommending this. https://javascript30.com/
* You don't know JS: A series of free lessons on JS https://github.com/getify/You-Dont-Know-JS
* $ Book: O'Reilly JS Pocket Reference. If you already know how to program, this can help you understand JS in a very short amount of time. Obviously you will need to practice to really get it, but this helped me to understand a lot of things very quickly. Great for train commute or downtime reading: https://www.amazon.com/JavaScript-Pocket-Reference-Activate-...