Lets leave out AI and ML for now.
[1] https://www.youtube.com/watch?v=4r7wHMg5Yjg
[2] my personal breakdown: 50% luck, 40% perseverance, 10% ability to retain details
Some people will check if this is really a critical thing to accomplish right now, and just work around it when it makes sense. This can be the difference between 100% done, six weeks late, and 95% done on time, with a small outstanding improvement left to complete. It may even be easier to do when other work is done first.
Sometimes you can't go around it -- then the honey badger does surely take the day! But I've found (and seen) a lot of success in asking yourself / a Product Owner if a feature can be delayed, or even cut.
Occasionally there will be a post on HN about someone who debugged a compiler bug or a even a hardware bug, and it lifts my spirits.
As an engineering candidate, how do I display these traits?
As an interviewer, how can I test for these traits?
This is one trick I haven't figured out.
I can ask problems that require tenaciousness to dig all the way to the bottom. BUT motivations and incentives in a 45min interview and an ongoing job are very different. There's a higher reward in the job interview, and you know an upper bound to how much time it'll take.
I've hired people who aced that, but then were pretty lazy day to day, even for looking up trivial stuff like "you submitted a python code review that wouldn't even run because you made a typo in the method name."
Stories can help, but stories are (even assuming true and not borrowed) from a past version of the candidate which may not be the same as the present version.
So I just do the best I can, but also recognize that I won't necessarily get a 100% perfect employee no matter what questions that I ask. But "pretty good" is about all you can realistically hope for, I think.
There are two very important tests to consider hiring someone:
- how a candidate handles feedback and negative situations like disapproval and rejection
- whether they delegate thinking or take ownership of solving hard problems
If they fail either, that’s a deal-breaker. Also, make the candidate pipeline as uniform, fair and repeatable as possible.
- anonymizing resumes by masking pedigree, names, addresses, etc.
- ask generally the same questions, while branching differently based on their responses
- perform social and skills tests as similarly as possible
”Be the change you seek”
Yes, this involves a lot of online stalking people. Honey badger doesn't care.
Often, you can't find the problem, but you can find a point where checking code will trap the problem earlier. Slowly, crash by crash, you work backwards to the source of the problem. Eventually you can find the root cause.
I got out of that after a few years and into the more theoretical end of computing, including proof of correctness. It was useful, though, to learn what makes software unreliable from the bottom.
(This is part of why I'm so down on unsafe code in Rust. Rust has a good safety system. There are people with an attitude that "I'm so l33t I don't need the checking." They're not. They may create something which imposes a safety constraint on the caller, and later, someone else violates that constraint and creates a memory corruption bug. They write code which has an implicit undocumented invariant which is violated when someone else makes a later change. Those are bugs waiting to happen.)
1. User interface design. There are many programmers who "hate UI" to their detriment. Your software doesn't do anything until a human can use it, and use it correctly. Having a little UI background means my solo software is easier to use, I work more effectively with UI designers, and I design better APIs (because API design is also UI design).
2. Writing. If you measure the number of characters you type every day and which applications they go into, you'll probably discover you spend more time writing email, chat, code review comments, design documents, etc. than actual code. Even when writing code, a good fraction of it goes into naming, comments, and doc comments.
Writing improves all of those directly. It also taught me to invest in editing even more than I do in writing, which is a useful mindset to have for code. It helps me organize my thoughts more clearly, and choose better metaphors and names.
* The Design of Everyday Things
* The Inmates are Running the Asylum
* Any of Edward Tufte's books
* Usability Engineering
Consider the position of syntax in learning to program. When you first start, it seems daunting, and you spend all your time fixing compiler errors because you forgot a semicolon or whatever. Once you actually learn how to program though, the syntax and even sometimes higher order structures of a language will fall away as you start to think more abstractly about how to get the machine to do what you want.
This isn't a perfect analogy, but it's a similar kind of thing here: early in a programmer's career it seems like [ COBOL / SQL / HTML / Java / Ruby / NodeJS / $framework / Big Data(tm) / ML / etc] is The Thing to focus on, and that you'll become instantly more marketable if you develop that skill.
This is a little bit true in the very short term, but it burns out quickly as an approach, and cultivating Generalized Problem Solving -- including especially the motivation to solve any problem within range -- is much more valuable.
The famous quote from Musashi[1] comes to mind: “The primary thing when you take a sword in your hands is your intention to cut the enemy, whatever the means. Whenever you parry, hit, spring, strike or touch the enemy's cutting sword, you must cut the enemy in the same movement. It is essential to attain this. If you think only of hitting, springing, striking or touching the enemy, you will not be able actually to cut him.”
[1] https://www.goodreads.com/quotes/38725-the-primary-thing-whe...
I don't know how to show this to interviewers in the very brief time I have with them during screenings/technical interviews in most cases. I do research into any tools they use before the interview and do my homework on the company and interviewers. Do you have any advice on how we show initiative to employers?
You don't have to be a psychologist, just interested in other people, what your shared goals are, and confirming that you are working together to achieve them.
Especially in really culturally old school IT places you need to earn your (invisible) badges.
So you are definitely right but at many places you shoot yourself in the foot with that big time...
Probably this is not the case at every organisation but I see there is a strong force that makes people do things exactly the way they want and nothing else. To be honest, I think this behaviour is not at all limited to engineers...
But yeah, Soft skills, especially not caring only for oneself, are very helpful but they should be spread among the team.
Before going into software full time, I got a degree in structural engineering and a few years of experience in construction engineering and management. That experience can be easily parlayed into a job at myriad companies producing project management tools, construction tools, etc. It has been something that allowed me to stand out amongst other engineers applying for the same job. As far as any employer is concerned, all the applicants can probably write the same quality code, but the ability to claim knowledge of why we're building some given feature has been a great boon.
I use FHIR as an example because it's an excellent technology to investigate for someone new to health IT.
:(
You can start small and grow your skills in many directions: linear types, probabilistic model checking...
It involves a very neat but approachable branch of mathematics: abstract algebra.
Formal methods are on the verge of being a big thing in smart contract programming, where the code is short and failures are expensive.
I agree formal methods are great for smart contracts. Back in '08 when I was doing graduate work on the topic, some researchers were already talking about it, but the enabling technology (blockchain) was missing.
They are also great for real-time critical systems, especially if you go with a formal methodology, where you start with some axioms (e.g. two trains can't be in the same track partition) and progressively derive your system from these by applying formally verified transformations till you end up with the code to deploy.
The book itself contains references to much more advanced works such as Nielson & Nielson or TAPL. It doesn't cover one part of formal methods, (probabilistic) model checking.
I don't think I need to go into the details of why it's useful, but I think nearly every developer should have an idea of very common vulnerabilities and bugs and be able to catch them _before_ code gets committed.
This means introducing security into your design discussions, stand-ups, and your code reviews. Developing the "adversarial mindset" isn't horrible necessary for just any developer, but it does help you see more issues that you may otherwise miss out on.
I'm honestly not all that sure how you become the guy who an executive who knows nothing about security feels comfortable hiring. I'm also fairly sure that being good at #2 is somewhat orthogonal to being good at #1.
Database Administration. Another "you don't need it until you do" skill. Being able to track down the cause of a CPU bottleneck to a poor DB config saved the company the operational cost of 4 additional DB servers, not to mention the development cost of utilizing read replicas and write masters in the same code.
Re-emphesizing one mentioned previously: Writing. English is a fairly imprecise language and your processing nodes are way more flaky, but both can be worked around; need to be worked around on an almost daily basis.
If the goal is to be at Google/Amazon/etc, I'd probably suggest an overall strategy of "pick something relatively narrow, and be the best in the world at it". Big Tech firms tend to be the land of experts -- there are fewer job titles of "full-stack engineer", and more of "we have enough engineering resources to have specialists for everything".
For small companies (or small tech teams), it's the opposite. There is a ton of value of being able to be able to move up and down the stack -- Sales, Product, Design, Frontend, Backend, Devops... and pinch hit in any job capably as needed.
Other than that, being able to demonstrate specialized in the skill that you are applying for. If the job asks for Java for instance, make sure that your related expertise is demonstrated.
Non skill related, and really dear to me, is to think outside the box when looking for a job. Don't only apply for the obvious positions in large companies, search and go after less advertised positions that you can be competent in.
A caveat here. Not all, but many, remote positions exist because the company is hoping to get labor for cheaper than they can source it in their local market. In such instances, qualifications aren't going to matter that much. If you're a fairly senior level person, any reasonable salary expectation will exclude your consideration for the majority of remote positions.
Some companies are relatively shameless about this and announce that they have location-adjusted salaries (in the case of GitLab, they even have a public salary calculator that shows that they seriously underpay), etc., but many try to keep it under the covers since it would hurt their reputation and recruitment efforts if they weren't able to spring a low-ball on candidates.
If you're good, I would suggest that you just keep applying rather than assume that your qualifications are insufficient, aware that the majority of remote positions are hush-hush attempts at keeping payroll costs down.
Source: fairly senior, large part of my career has been remote.
But it's unnerving to be in a spot where you MUST work remote. I've been working remote for over a decade now, but I'm still kinda amazed I've managed to keep it up for this long.
I've had more than one promising candidate that just blew the phone screen or interview for various reasons.
Speak up, don't mumble, don't take the call in a coffee shop or outside in the wind ffs.
You'd be surprised how much this affects my hiring decision (continue on the process and explain to my team/boss why I recommended a mumbler with a barking dog).
For most people, they start with easy stuff. Skills which are not niche, which are fairly known. You slowly get accustomed and start working in it and pick related technologies from there and keep moving.
I would suggest start with any kind of web programming(html, css, any backend language) and explore from there. Also, enterprise products/technologies are pretty niche but they have a high barrier of entry. But once you know any web programming(either UI or backend), it is pretty easy to switch to these niches. Just start and keep going.
With well-structured code, as with a well-structured essay, you can learn to skim to get an overview before your deep dive by focusing on the beginning and end of every chapter/paragraph/etc (e.g. function definition and return statement; gate for each block; treating header files as Table of Contents; etc). But most code is no better structured than your average Tumblr post, so that's kind of hit and miss.
And as with reading human language, you can learn techniques for taking notes as you go along to guide yourself or remember important details; but the technique that one person finds helpful may be a waste of time for another.
But such skills are insanely hard to attain. Some people simply give up on trying.
Many companies also have custom in-house code that needs to be modernized and better integrated due to ongoing changes in their business processes. In big companies most of the major apps are 3rd party/outsourced, but quite a bit is not, and much commercial code needs to be custom fitted, made backward compatible, or made compliant.
In terms of career progression, a lot of companies are more willing to hand control to a developer that can articulate their ideas to a non-technical person, or display confidence in their skills to a room of external stakeholders. Additionally, the ability to sell yourself or an idea to others is a great one if you're in the startup space, or working with startups.
Since the guy you are talking to is applying for remote positions this would be even more important to me. For remote work you need people who are reliable and don't need constant handholding.
Hiring good front-end developers on the other hand....