10 ms·

I disagree. If you can’t tell the difference between a smooth talker and strong technical competence you are probably interested in the wrong qualities. I have

I disagree. If you can’t tell the difference between a smooth talker and strong technical competence you are probably interested in the wrong qualities. I have interviewed enough now to see why some companies cannot figure it out. Ask yourself if you really actually want a senior or a strong junior. It comes down to interest. A good senior got that way because they like solving challenging problems. They are not interested in trendy framework bullshit. In other words talk about the problems and potential solutions. Are things in place to make the job easier? Seniors don’t need easier and this is a huge turnoff. When I hear companies try to sell me with frameworks and process I know they are blowing smoke. At the very least they are boring and at worst you will be working with incompetent people who are as self-diluted as the company. I agree that filtering candidates is a good idea though. The reason why some companies cannot figure this out is because they don’t value the problems at hand. They need bodies to put fingers on keyboards and are willing to pay more for people who don’t completely suck. Experience and competence are not the same as excellence but considering the candidate pool I can see why companies compromise on quality.

fipple 8y ago
No. The difference between talking (very intelligently) and doing is huge, and a sports analogy might be illustrative. If you ask detailed questions about football to hire a NFL quarterback, your most intelligent responses will probably be from a coach. “How should you change the position of your right shoulder if you see that a fast edge rusher is approaching you from the left side and you have two open receivers?” A coach like Bill Belichick might have a fantastic, detailed answer demonstrating a thorough understanding of every aspect of football past and present, but he could never make the throw himself.
- austincheney 8y ago
  > The difference between talking (very intelligently) and doing is huge To be fair it is environment dependent more than anything else. Forget competence, charisma, intelligence, and everything else about the candidate that could bias their selection and instead look at processes and code already in place the new candidate is jumping into. Does the environment strongly favor original ideas/solutions or does it dictate the narrow acceptance in the most narrow of boundaries? I have been on both ends of this as well. It is common in software for shops to define success in extraordinarily shallow terms such as whether you are using spaces versus tabs and indenting properly. Another example I experienced last year is whether you should write a giant monster configuration or a small function that receives a single argument. The reasons why shops coat themselves in blankets of code style and configuration is because they typically don't trust their developers and instead strive for a normalized baseline. They are looking for wonderful solutions, but rather task completion. The lack of conformance isn't necessarily an indication of lower capability, but it is an indication of incompatibility. Competence and conformance are wildly out of sync when the candidate is misjudged relative to the work available. That is completely an assignment failure opposed to a candidate failure. Having gone through this myself it has taught me to ask very probing questions, as a candidate, during the interview. If, as a senior, I can determine I will not be a good fit I will happily disqualify myself. > A coach like Bill Belichick might have a fantastic, detailed answer demonstrating a thorough understanding of every aspect of football past and present, but he could never make the throw himself. Would you really hire a coach to be your quarterback? Is that a thought you would really entertain? Even if that coach could do that job he/she would be more valuable doing other work. I would consider this a solid example of interviewer/assignment failure.
  - honestoHeminway 8y ago
    >Does the environment accept ideas? That is where i get started- how do they expect the ideas? Do you just got to have a nice solution - or do they expect solutionpaths, with all problems worked out and a polished result plus estimate at the end. Ideas alone are worthless. Realizations - and the path through the labyrinth of failure is whats valuable.
  - jlelonm 8y ago
    > Having gone through this myself it has taught me to ask very probing questions, as a candidate, during the interview. Like what questions? I'm assuming the work you're looking for is more along the lines of "wonderful solutions" as opposed to "task completion" - is it as simple as asking, "How anal are you guys about code syntax and whatnot?" and, "How hard are your problems actually?" Or is it more subtle than that?
    - austincheney 8y ago
      Here are some I thought of off the top of my head. These are based upon things I actually encountered. What if I were to provide a solution that executes much faster, requires less documentation, passes test automation, and is a quarter of the code but ignores the framework or standard code style? The standard DOM methods perform thousands of times faster than other options for interacting with markup. I can prove this with numbers. Code like that is not popular. Will I be allowed to write unpopular objectively superior code? If I can reduce the application build from 5 minutes to 5 seconds will you let me rewrite the build from Java to Typescript? A/B testing is a powerful way to determine preferential user behavior and a measured increase in conversion. Will I be allowed to write inward facing experiments to test developer behavior? What if I provide a function as a solution the makes use of scope and nested functions but offers no support for inheritance? Is it better to complete a task in 1 hour with original code plus tests or extend existing components with risk of regression and 4 days of effort?
      - handyman5 8y ago
        A couple of these questions would be at least yellow flags for me as an interviewer or hiring manager, as they indicate a strong bias for throwing away existing systems ("ignores the framework", "rewrite the build", "original code"). There's a great quote from Lou Montulli[1]: > I laughed heartily as I got questions from one of my former employees about FTP code the he was rewriting. It had taken 3 years of tuning to get code that could read the 60 different types of FTP servers, those 5000 lines of code may have looked ugly, but at least they worked. Those frameworks and existing components most likely have a lot of hard-won experience embedded in them, and I would be uncomfortable hiring someone who did not appear to understand or appreciate that. See also: Chesterton's fence[2]. [1]: https://www.joelonsoftware.com/2000/05/26/20000526/ https://www.joelonsoftware.com/2000/05/26/20000526/ [2]: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
- treypitt 8y ago
  Maybe this is unique to sports? Do other fields exist where a BB-esque expert is totally incapable of practicing? The greatest movie critics probably can't direct or write for crap, but they're not commenting on how the movie was produced, just its output
  - C1sc0cat 8y ago
    You obviously haven't seen Mark Kermodes series on the BBC where he covers exactly this.
    - cududa 8y ago
      Why talk to someone so condescendingly? I mean, what percentage of people do you epxpect to HAVE seen this bit of obscure media you seem to hold as seminal?
      - C1sc0cat 8y ago
        If the parent makes the unjustified statement that all cinema reviewers no know nothing about how film is made why not. And I was not being condescending BTW.
        function_seven 8y ago
        Parent made no such statement. Read it again: > The greatest movie critics probably can't direct or write for crap They may know a lot about how a film is made. It does not follow that they could sit in the director's chair, or write a decent screenplay. (And yet, they could still be great at critiquing films!) This is a valid point. Just knowing how something is made doesn't necessarily mean you know how to make it. It's the difference between a designer and an implementer. Or architect and builder.
  - bluedino 8y ago
    Could Albert Einstien have actually built a particle accelerator or an atomic bomb?
  - 8y ago
- commandlinefan 8y ago
  > hire a NFL quarterback That analogy highlights what’s irritating me about this post and this entire thread discussion - there are 1,696 players in the NFL, each with an average salary of $1.9 million. When people talk about hiring “senior engineers”, they behave as thought they’re auditioning an NFL quarterback - the 1 out of 100,000,000 people who can actually perform at that level. For a salary of, on average, about $100,000. When you start out - offering comparatively little but looking for Tom Brady, you’ll pass over pretty much everybody, because the person you’re looking for won’t just not interview with you, they probably don’t exist. After a few months, you’ll relax your standards, and after a few more, you’ll relax them even more and end up hiring a comparative retard like myself - somebody with only a mere 25 years of hands-on development experience and a bachelor’s and master’s degree in CS along with a couple of publications. But if I presented in the first few rounds of interviews, back when you were looking for the guy who could derive the tortoise and the hare algorithm in 30 seconds in front of five people in a boardroom, you would have passed.
tyre 8y ago
I hear what you're saying, but I think you're maybe creating a straw man argument here. A smooth talking engineer isn't one who sounds like a used car salesperson or is just hyped about the latest trendy framework. There are people who can talk through challenging problems at their former companies and how the problems were solved. They can tell you everything you'd want to hear because it's true. Except…they didn't implement it. Maybe they are best friends with the person who did and understand in detail about the tradeoffs and the neat hacks and the insights learned along the way, but couldn't build it themselves. Those are the "smooth talkers" of the engineering world. Those are the people you can't catch just through a verbal interview. On a related note: > If you can’t tell the difference between a smooth talker and strong technical competence you are probably interested in the wrong qualities. I have interviewed enough now to see why some companies cannot figure it out. Ask yourself if you really actually want a senior or a strong junior. My dude. Look at who you're replying to.
- Annatar 8y ago
  "Principal engineer"? Do you actually have an engineering degree? Have you formal education in engineering? What is system engineering? It's not just you; the entire IT industry is suffering from systemic curriculum vitae bloat. That's why the working conditions are so bad in the professional sense.
  - pjmlp 8y ago
    I do, in my home country it is not legal to sign off projects as engineer if not certified by the Engineering Order as such. A certain level of quality is expected, not labeling one selfs as engineers after 1 month bootcamp.
    - mcv 8y ago
      I have no idea if there are rules in my country about calling yourself an "engineer", but you can only use the title 'ir' or 'ing', both of which mean ingenieur, which translates to engineer, if you've graduated from a technical university or high-level technical school (technical college? higher trade school? 'ing' is from a level lower than a university degree).
aprdm 8y ago
This is a good post. Have been in the UK startup environment it was crazy how many companies got funding but didn't had a strong senior in their software department. Because of this their hiring process was aimed to hire more "strong juniors" even tho they didn't realize it. A strong senior is a person who completely changes how you are even approaching the problem or someone who shows you problems you hadn't seen before. They often see tech in the context of business as well. As you said, usually, they can't be bothered about learning the new framework of the month or new backend language of the month, but, they have a set of battle proven tools to solve tech problems for businesses. P.S: I do find it hard to distinguish between bullshit talkers and people who actually get stuff done in the interview process.
- bartread 8y ago
  > A strong senior is a person who completely changes how you are even approaching the problem or someone who shows you problems you hadn't seen before. I think this is overstated. Disruption for the sake of it is often not that helpful in the context of the business (although, in fairness, you do go on to state they often see tech in that context). I much prefer people who are delivery focused to those who are overly idealistic or want to change everything out of the gate: a good senior understands priorities and knows when to make a trade-off to live with a sub-optimal situation or solution in one area in order to deliver greater value elsewhere.
  - lugg 8y ago
    The higher you go the more compromises you have to make. That said, nobody is talking about disruption, just wisdom. It just so happens, sometimes that wisdom will tell you that shipping shit out the door in the name of delivery focus is going to cost you more than its worth in the long run. Calling them overly idealistic to justify your laziness just makes you look bad. I'd say a truly good senior can tell the difference between a startup and a mature company and adapt accordingly. It takes one set of skills to ship shit out the door as quick as possible and an entirely different set of skills to come in and clean up the mess the kids left behind. This is why you are selling. Not buying. Because nobody wants to clean up your delivery focused mess.
webdood90 8y ago
Are things in place to make the job easier? Seniors don’t need easier and this is a huge turnoff. What? I feel like you have a very narrow-minded idea of what sr engineers want.
- drb91 8y ago
  Well, unambitious seniors are a good bet on who not to hire. They’ll only work what you pay them for, those lazy bastards!
  - jjeaff 8y ago
    I think I've read in quite a few places that most great programmers are essentially lazy.
    - carlmr 8y ago
      A special kind of lazy where they will spend inordinate amounts of effort not to do the same routine task again.
    - bigiain 8y ago
      "We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris." -- LarryWall Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don't have to answer so many questions about it. Impatience: The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to. Hubris: The quality that makes you write (and maintain) programs that other people won't want to say bad things about. (That quoite's originally from Programming Perl 1st edition in 1991, the explanations I think didn't show up until edition 2 in '96 or so...)
- austincheney 8y ago
  I differentiate between simple and easy. They aren't the same.
mandeepj 8y ago
> Are things in place to make the job easier? Seniors don’t need easier and this is a huge turnoff. What? It requires a special craft to design simpler components. Most of the people don't even see it. This is where your senior skills will shine when you'll make it work like a charm as compared to the previous state. If you don't see the friction or can't reduce it then please take the first exit out.
- austincheney 8y ago
  I think you are conflating simple and easy. They aren't the same. Simple suggests less code, fewer pieces, and a shorter path between code and solution. Easier suggests least effort and less to look at. Simple isn't easy. The primary difference between simple and easy are decisions. A good senior will spend more energy on considerations for appropriate decisions than the actual work.
  - mandeepj 8y ago
    Good definition of 'Simple'. Simple and easy may not be the same but there are situations where they are similar. For e.g. - for production deployment, I could either put the entire office upside down. Fires across the departments. Broken applications. Rollbacks. Or, I can automate all of our QA test cases and have a one-click deployment. No huss or fuss. I'm sure after having this experience, someone will definitely say - well, this was easy. Anyway, good discussion.
  - feliksik 8y ago
    One of the best engineering talks is about this notion that simple!=easy : https://www.infoq.com/presentations/Simple-Made-Easy https://www.infoq.com/presentations/Simple-Made-Easy This is surprisingly often not understood, even by people I showed the video. And I am not sure why. But I do think it's necessary in out field to start understanding this much more deeply, especially for senior engineers.
  - gerbilly 8y ago
    > I think you are conflating simple and easy. I like to state it as complex vs. difficult. Finding a bug in ten thousand lines of crappy VB code code is 'difficult', but not fun. Writing an space/time efficient implementation of level set topology optimization is complex. Senior developers usually love complex problems, but hate merely difficult problems.
qualsiasi 8y ago
I agree with your comments, but let me share my 2c on "trendy framework bs". Most of interviews I've done to candidates ended up in discussing technology trends and googling around for cool open source projects, libraries and so. This, to me, is a good indicator - as long as you bring them up when discussing relevant problems, this means you thought about a problem and researched prior art to avoid re-inventing the wheel. Also we tend to end up discussing pro and cons of any given technology and so on. This at the end is a key indicator you're talking to a passionate developer. And passion usually makes someone good at programming. When it comes to soft skills, usually having such a kind of discussion you can figure out also someones behaviour in most work scenarios (to me, having a good "discussion" mode means you're likely to be fit for team work).
- austincheney 8y ago
  Reinventing the wheel is a cliche I have grown to detest. I have found that cliche is abused 9 times out of 10 to avoid the deep dive into a problem. On the other hand, approaching the problem again allows the developer to consider the precision of current solutions or consider a simpler solution. Good seniors aren’t afraid of making decisions.
collyw 8y ago
The question to ask is "why" they did something a particular way. If they start rattling off something that sounds like the marketing page of shiny new tech, the they are probably doing resume driven development rather than actually solving the problem in the best way that they can. But then some people seem to value that - I don't.
BrissyCoder 8y ago
I don't know how much experience you have as a professional developer but I can barely remember the problems I solved last week let only any interesting ones I've solved in the past 10 years.
- bigiain 8y ago
  I have maybe half a dozen really interesting stories, and maybe a dozen or two interesting but only to the right crowd stories - from a career spanning a bit over 24 years. And a bunch of war stories about why we shouldn't do things that way, because of the problems we discovered trying that in 1998 or 2003... (And occasionally the "we should try that again because it didn't work back when our colocated production servers had 486's and 320Mb disks - but it'll probably work just fine as a mobile app now"...)
watwut 8y ago
You recognize good senior by not being interested in new technologies and things that makes the job easier? That is a bit dubious.
PaulHoule 8y ago
I have been amazed at how many "data science" interview questions can be answered with "look it up in the hash table" or "look it up in the literature". That last one is a real problem-solving strategy, I can't tell you exactly how to balance a Red-Black tree but I know what a Red-Black tree is and where to look up the algorithm for balancing it and I think that's good enough. One of the master skills for interviewing is "don't choke." Often good people will make mistakes under the pressure of interviewing and will drop out. When it comes to a practical session there is the same issue that some good people will choke. Just the sample of who chokes in which environment when is different. Issues like this turn up in all cases where people try to measure merit. For instance, it is known that some low-SES (socioeconomic status) people will choke on standardized tests like the SAT or IQ tests. It is also known that some high-SES people are as dumb as posts and will have that revealed by standardized tests which are harder to bribe or bullshit. The hostility towards testing is explained by the combination of those two groups: primarily the Emperor doesn't want you to see they have no clothes, but people have sympathy for poor people.
gerbilly 8y ago
> The reason why some companies cannot figure this out is because they don’t value the problems at hand. They need bodies to put fingers on keyboards Exactly this. Too many companies are availability focused instead of ability focused. The reason? When your processes and engineering are weak, you need people available 24/7 to put out fires. When I interview for a position, I'm interviewing them as much as they are me. One of the biggest asymmetries in the whole hiring process, is that of course every company will tell you they have the best development processes, frameworks and code to work on. They may even believe it because they don't know better. Then you take the job and are stuck fighting fires on a big ball of mud codebase that takes over your life. If you want to standout as a candidate, try and probe and really find out how good their 'culture is.' Interview them back. One of the best questions for getting to the real answer is: "What are your expectations for availability?" If they expect availability from you after hours, then their stack is likely unstable because the need availability to keep it running. If you are lucky enough when you are senior and good at what you do, you don't have to put up with that. I often tell them about a the third of the way through the interview: "I'm not an availability guy, I'm an ability guy." They often are surprised by the statement. And the discussion that follows it usually tells me whether I want to work for them or not.

fipple 8y ago

No. The difference between talking (very intelligently) and doing is huge, and a sports analogy might be illustrative. If you ask detailed questions about football to hire a NFL quarterback, your most intelligent responses will probably be from a coach. “How should you change the position of your right shoulder if you see that a fast edge rusher is approaching you from the left side and you have two open receivers?” A coach like Bill Belichick might have a fantastic, detailed answer demonstrating a thorough understanding of every aspect of football past and present, but he could never make the throw himself.

austincheney 8y ago
> The difference between talking (very intelligently) and doing is huge To be fair it is environment dependent more than anything else. Forget competence, charisma, intelligence, and everything else about the candidate that could bias their selection and instead look at processes and code already in place the new candidate is jumping into. Does the environment strongly favor original ideas/solutions or does it dictate the narrow acceptance in the most narrow of boundaries? I have been on both ends of this as well. It is common in software for shops to define success in extraordinarily shallow terms such as whether you are using spaces versus tabs and indenting properly. Another example I experienced last year is whether you should write a giant monster configuration or a small function that receives a single argument. The reasons why shops coat themselves in blankets of code style and configuration is because they typically don't trust their developers and instead strive for a normalized baseline. They are looking for wonderful solutions, but rather task completion. The lack of conformance isn't necessarily an indication of lower capability, but it is an indication of incompatibility. Competence and conformance are wildly out of sync when the candidate is misjudged relative to the work available. That is completely an assignment failure opposed to a candidate failure. Having gone through this myself it has taught me to ask very probing questions, as a candidate, during the interview. If, as a senior, I can determine I will not be a good fit I will happily disqualify myself. > A coach like Bill Belichick might have a fantastic, detailed answer demonstrating a thorough understanding of every aspect of football past and present, but he could never make the throw himself. Would you really hire a coach to be your quarterback? Is that a thought you would really entertain? Even if that coach could do that job he/she would be more valuable doing other work. I would consider this a solid example of interviewer/assignment failure.
- honestoHeminway 8y ago
  >Does the environment accept ideas? That is where i get started- how do they expect the ideas? Do you just got to have a nice solution - or do they expect solutionpaths, with all problems worked out and a polished result plus estimate at the end. Ideas alone are worthless. Realizations - and the path through the labyrinth of failure is whats valuable.
- jlelonm 8y ago
  > Having gone through this myself it has taught me to ask very probing questions, as a candidate, during the interview. Like what questions? I'm assuming the work you're looking for is more along the lines of "wonderful solutions" as opposed to "task completion" - is it as simple as asking, "How anal are you guys about code syntax and whatnot?" and, "How hard are your problems actually?" Or is it more subtle than that?
  - austincheney 8y ago
    Here are some I thought of off the top of my head. These are based upon things I actually encountered. What if I were to provide a solution that executes much faster, requires less documentation, passes test automation, and is a quarter of the code but ignores the framework or standard code style? The standard DOM methods perform thousands of times faster than other options for interacting with markup. I can prove this with numbers. Code like that is not popular. Will I be allowed to write unpopular objectively superior code? If I can reduce the application build from 5 minutes to 5 seconds will you let me rewrite the build from Java to Typescript? A/B testing is a powerful way to determine preferential user behavior and a measured increase in conversion. Will I be allowed to write inward facing experiments to test developer behavior? What if I provide a function as a solution the makes use of scope and nested functions but offers no support for inheritance? Is it better to complete a task in 1 hour with original code plus tests or extend existing components with risk of regression and 4 days of effort?
    - handyman5 8y ago
      A couple of these questions would be at least yellow flags for me as an interviewer or hiring manager, as they indicate a strong bias for throwing away existing systems ("ignores the framework", "rewrite the build", "original code"). There's a great quote from Lou Montulli[1]: > I laughed heartily as I got questions from one of my former employees about FTP code the he was rewriting. It had taken 3 years of tuning to get code that could read the 60 different types of FTP servers, those 5000 lines of code may have looked ugly, but at least they worked. Those frameworks and existing components most likely have a lot of hard-won experience embedded in them, and I would be uncomfortable hiring someone who did not appear to understand or appreciate that. See also: Chesterton's fence[2]. [1]: https://www.joelonsoftware.com/2000/05/26/20000526/ https://www.joelonsoftware.com/2000/05/26/20000526/ [2]: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
treypitt 8y ago
Maybe this is unique to sports? Do other fields exist where a BB-esque expert is totally incapable of practicing? The greatest movie critics probably can't direct or write for crap, but they're not commenting on how the movie was produced, just its output
- C1sc0cat 8y ago
  You obviously haven't seen Mark Kermodes series on the BBC where he covers exactly this.
  - cududa 8y ago
    Why talk to someone so condescendingly? I mean, what percentage of people do you epxpect to HAVE seen this bit of obscure media you seem to hold as seminal?
    - C1sc0cat 8y ago
      If the parent makes the unjustified statement that all cinema reviewers no know nothing about how film is made why not. And I was not being condescending BTW.
      - function_seven 8y ago
        Parent made no such statement. Read it again: > The greatest movie critics probably can't direct or write for crap They may know a lot about how a film is made. It does not follow that they could sit in the director's chair, or write a decent screenplay. (And yet, they could still be great at critiquing films!) This is a valid point. Just knowing how something is made doesn't necessarily mean you know how to make it. It's the difference between a designer and an implementer. Or architect and builder.
- bluedino 8y ago
  Could Albert Einstien have actually built a particle accelerator or an atomic bomb?
- 8y ago
commandlinefan 8y ago
> hire a NFL quarterback That analogy highlights what’s irritating me about this post and this entire thread discussion - there are 1,696 players in the NFL, each with an average salary of $1.9 million. When people talk about hiring “senior engineers”, they behave as thought they’re auditioning an NFL quarterback - the 1 out of 100,000,000 people who can actually perform at that level. For a salary of, on average, about $100,000. When you start out - offering comparatively little but looking for Tom Brady, you’ll pass over pretty much everybody, because the person you’re looking for won’t just not interview with you, they probably don’t exist. After a few months, you’ll relax your standards, and after a few more, you’ll relax them even more and end up hiring a comparative retard like myself - somebody with only a mere 25 years of hands-on development experience and a bachelor’s and master’s degree in CS along with a couple of publications. But if I presented in the first few rounds of interviews, back when you were looking for the guy who could derive the tortoise and the hare algorithm in 30 seconds in front of five people in a boardroom, you would have passed.

tyre 8y ago

I hear what you're saying, but I think you're maybe creating a straw man argument here. A smooth talking engineer isn't one who sounds like a used car salesperson or is just hyped about the latest trendy framework. There are people who can talk through challenging problems at their former companies and how the problems were solved. They can tell you everything you'd want to hear because it's true. Except…they didn't implement it. Maybe they are best friends with the person who did and understand in detail about the tradeoffs and the neat hacks and the insights learned along the way, but couldn't build it themselves. Those are the "smooth talkers" of the engineering world. Those are the people you can't catch just through a verbal interview. On a related note: > If you can’t tell the difference between a smooth talker and strong technical competence you are probably interested in the wrong qualities. I have interviewed enough now to see why some companies cannot figure it out. Ask yourself if you really actually want a senior or a strong junior. My dude. Look at who you're replying to.

Annatar 8y ago
"Principal engineer"? Do you actually have an engineering degree? Have you formal education in engineering? What is system engineering? It's not just you; the entire IT industry is suffering from systemic curriculum vitae bloat. That's why the working conditions are so bad in the professional sense.
- pjmlp 8y ago
  I do, in my home country it is not legal to sign off projects as engineer if not certified by the Engineering Order as such. A certain level of quality is expected, not labeling one selfs as engineers after 1 month bootcamp.
  - mcv 8y ago
    I have no idea if there are rules in my country about calling yourself an "engineer", but you can only use the title 'ir' or 'ing', both of which mean ingenieur, which translates to engineer, if you've graduated from a technical university or high-level technical school (technical college? higher trade school? 'ing' is from a level lower than a university degree).

aprdm 8y ago

This is a good post. Have been in the UK startup environment it was crazy how many companies got funding but didn't had a strong senior in their software department. Because of this their hiring process was aimed to hire more "strong juniors" even tho they didn't realize it. A strong senior is a person who completely changes how you are even approaching the problem or someone who shows you problems you hadn't seen before. They often see tech in the context of business as well. As you said, usually, they can't be bothered about learning the new framework of the month or new backend language of the month, but, they have a set of battle proven tools to solve tech problems for businesses. P.S: I do find it hard to distinguish between bullshit talkers and people who actually get stuff done in the interview process.

bartread 8y ago
> A strong senior is a person who completely changes how you are even approaching the problem or someone who shows you problems you hadn't seen before. I think this is overstated. Disruption for the sake of it is often not that helpful in the context of the business (although, in fairness, you do go on to state they often see tech in that context). I much prefer people who are delivery focused to those who are overly idealistic or want to change everything out of the gate: a good senior understands priorities and knows when to make a trade-off to live with a sub-optimal situation or solution in one area in order to deliver greater value elsewhere.
- lugg 8y ago
  The higher you go the more compromises you have to make. That said, nobody is talking about disruption, just wisdom. It just so happens, sometimes that wisdom will tell you that shipping shit out the door in the name of delivery focus is going to cost you more than its worth in the long run. Calling them overly idealistic to justify your laziness just makes you look bad. I'd say a truly good senior can tell the difference between a startup and a mature company and adapt accordingly. It takes one set of skills to ship shit out the door as quick as possible and an entirely different set of skills to come in and clean up the mess the kids left behind. This is why you are selling. Not buying. Because nobody wants to clean up your delivery focused mess.

webdood90 8y ago

Are things in place to make the job easier? Seniors don’t need easier and this is a huge turnoff. What? I feel like you have a very narrow-minded idea of what sr engineers want.

drb91 8y ago
Well, unambitious seniors are a good bet on who not to hire. They’ll only work what you pay them for, those lazy bastards!
- jjeaff 8y ago
  I think I've read in quite a few places that most great programmers are essentially lazy.
  - carlmr 8y ago
    A special kind of lazy where they will spend inordinate amounts of effort not to do the same routine task again.
  - bigiain 8y ago
    "We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris." -- LarryWall Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don't have to answer so many questions about it. Impatience: The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to. Hubris: The quality that makes you write (and maintain) programs that other people won't want to say bad things about. (That quoite's originally from Programming Perl 1st edition in 1991, the explanations I think didn't show up until edition 2 in '96 or so...)
austincheney 8y ago
I differentiate between simple and easy. They aren't the same.

mandeepj 8y ago

> Are things in place to make the job easier? Seniors don’t need easier and this is a huge turnoff. What? It requires a special craft to design simpler components. Most of the people don't even see it. This is where your senior skills will shine when you'll make it work like a charm as compared to the previous state. If you don't see the friction or can't reduce it then please take the first exit out.

austincheney 8y ago
I think you are conflating simple and easy. They aren't the same. Simple suggests less code, fewer pieces, and a shorter path between code and solution. Easier suggests least effort and less to look at. Simple isn't easy. The primary difference between simple and easy are decisions. A good senior will spend more energy on considerations for appropriate decisions than the actual work.
- mandeepj 8y ago
  Good definition of 'Simple'. Simple and easy may not be the same but there are situations where they are similar. For e.g. - for production deployment, I could either put the entire office upside down. Fires across the departments. Broken applications. Rollbacks. Or, I can automate all of our QA test cases and have a one-click deployment. No huss or fuss. I'm sure after having this experience, someone will definitely say - well, this was easy. Anyway, good discussion.
- feliksik 8y ago
  One of the best engineering talks is about this notion that simple!=easy : https://www.infoq.com/presentations/Simple-Made-Easy https://www.infoq.com/presentations/Simple-Made-Easy This is surprisingly often not understood, even by people I showed the video. And I am not sure why. But I do think it's necessary in out field to start understanding this much more deeply, especially for senior engineers.
- gerbilly 8y ago
  > I think you are conflating simple and easy. I like to state it as complex vs. difficult. Finding a bug in ten thousand lines of crappy VB code code is 'difficult', but not fun. Writing an space/time efficient implementation of level set topology optimization is complex. Senior developers usually love complex problems, but hate merely difficult problems.

qualsiasi 8y ago

I agree with your comments, but let me share my 2c on "trendy framework bs". Most of interviews I've done to candidates ended up in discussing technology trends and googling around for cool open source projects, libraries and so. This, to me, is a good indicator - as long as you bring them up when discussing relevant problems, this means you thought about a problem and researched prior art to avoid re-inventing the wheel. Also we tend to end up discussing pro and cons of any given technology and so on. This at the end is a key indicator you're talking to a passionate developer. And passion usually makes someone good at programming. When it comes to soft skills, usually having such a kind of discussion you can figure out also someones behaviour in most work scenarios (to me, having a good "discussion" mode means you're likely to be fit for team work).

austincheney 8y ago
Reinventing the wheel is a cliche I have grown to detest. I have found that cliche is abused 9 times out of 10 to avoid the deep dive into a problem. On the other hand, approaching the problem again allows the developer to consider the precision of current solutions or consider a simpler solution. Good seniors aren’t afraid of making decisions.

collyw 8y ago

The question to ask is "why" they did something a particular way. If they start rattling off something that sounds like the marketing page of shiny new tech, the they are probably doing resume driven development rather than actually solving the problem in the best way that they can. But then some people seem to value that - I don't.

BrissyCoder 8y ago

I don't know how much experience you have as a professional developer but I can barely remember the problems I solved last week let only any interesting ones I've solved in the past 10 years.

bigiain 8y ago
I have maybe half a dozen really interesting stories, and maybe a dozen or two interesting but only to the right crowd stories - from a career spanning a bit over 24 years. And a bunch of war stories about why we shouldn't do things that way, because of the problems we discovered trying that in 1998 or 2003... (And occasionally the "we should try that again because it didn't work back when our colocated production servers had 486's and 320Mb disks - but it'll probably work just fine as a mobile app now"...)

watwut 8y ago

You recognize good senior by not being interested in new technologies and things that makes the job easier? That is a bit dubious.

PaulHoule 8y ago

I have been amazed at how many "data science" interview questions can be answered with "look it up in the hash table" or "look it up in the literature". That last one is a real problem-solving strategy, I can't tell you exactly how to balance a Red-Black tree but I know what a Red-Black tree is and where to look up the algorithm for balancing it and I think that's good enough. One of the master skills for interviewing is "don't choke." Often good people will make mistakes under the pressure of interviewing and will drop out. When it comes to a practical session there is the same issue that some good people will choke. Just the sample of who chokes in which environment when is different. Issues like this turn up in all cases where people try to measure merit. For instance, it is known that some low-SES (socioeconomic status) people will choke on standardized tests like the SAT or IQ tests. It is also known that some high-SES people are as dumb as posts and will have that revealed by standardized tests which are harder to bribe or bullshit. The hostility towards testing is explained by the combination of those two groups: primarily the Emperor doesn't want you to see they have no clothes, but people have sympathy for poor people.

gerbilly 8y ago

> The reason why some companies cannot figure this out is because they don’t value the problems at hand. They need bodies to put fingers on keyboards Exactly this. Too many companies are availability focused instead of ability focused. The reason? When your processes and engineering are weak, you need people available 24/7 to put out fires. When I interview for a position, I'm interviewing them as much as they are me. One of the biggest asymmetries in the whole hiring process, is that of course every company will tell you they have the best development processes, frameworks and code to work on. They may even believe it because they don't know better. Then you take the job and are stuck fighting fires on a big ball of mud codebase that takes over your life. If you want to standout as a candidate, try and probe and really find out how good their 'culture is.' Interview them back. One of the best questions for getting to the real answer is: "What are your expectations for availability?" If they expect availability from you after hours, then their stack is likely unstable because the need availability to keep it running. If you are lucky enough when you are senior and good at what you do, you don't have to put up with that. I often tell them about a the third of the way through the interview: "I'm not an availability guy, I'm an ability guy." They often are surprised by the statement. And the discussion that follows it usually tells me whether I want to work for them or not.