There's a lot of things you can't buy in IT. There's a lot of things you don't need to either because they are free. For all this you must find people who are passionate and have interests aligned to your own. This is how I aim to hold the interviews I conduct for infrastructure engineers. The most important question I ask is "Why do you want to work in this position?". 10 years ago I used to care mostly about candidate know-how, now I care mostly about drive.
You Can't Buy Integration
81–90 of 143 posts
Re: You Can't Buy Integration
#82Earlier quoted context omitted.
I got bounced off a front-end job once, for not being good enough at React. Mind you I've been building SPA's since they weren't "a thing" and today I mostly use Vue. But for that role, they didn't like my lack of .env variables in the front-end (such as for things that end up in the HTML), after a 3 hours coding test, and a couple of minor React-y tid bits they couldn't even clarify. Basically, not "idiomatic". Mean…
TL;DR: I think you're seriously misguided. I think you're missing the point on every subject you touched on and I likely would not hire you either. For one, most frontend developers now use environment variables to feed in configuration specific data, most notably URLs and feature flags, so that they don't need to do find/replace operations in the final scripts (most notably, minified bundles). It really has nothing…
Thanks for the feedback. I hope we never cross path professionally! All the best.
Re: You Can't Buy Integration
#83There's a lot of things you can't buy in IT. There's a lot of things you don't need to either because they are free. For all this you must find people who are passionate and have interests aligned to your own. This is how I aim to hold the interviews I conduct for infrastructure engineers. The most important question I ask is "Why do you want to work in this position?". 10 years ago I used to care mostly about candid…
That particular question is a major red flag to me as an interviewee, maybe because most people who ask it are not interested in an honest answer (the most honest being: "you offer money for work, I offer work for money"), but have been told by some HR voodoo master that this almost-ritual incantation reveals deep psychological insights into the interviewee's mind. At best, it only tells you if they prepared by memorizing ideal answers and can lie convincingly.
An infrastructure engineer's top motivation does not have to experience a deep appreciation of the faux philosophy in your founder's ghostwritten business tales book for him/her to be an effective employee. Things like soft skills and technical know-how are a lot more important - things that cannot be easily faked in an interview situation.
The best interviews are those that do not follow a script. Remember: In a job interview, the potential hire is not the only one on trial.
Re: You Can't Buy Integration
#84Business logic happens line by line between interfaces. Coding may be all ifs and for loops, but when it comes to implementing a new feature, having chosen carefully where to draw the line between, say, your model and your view can be the difference between a 10 line patch and a complete rewrite . If you don’t have a culture of code review then maybe the rewrite will fly, bugs and all, through to production. If howev…
The line “coding is just if statements” really annoys me. I used to think this earlier in my career. It’s technically true but it means that you haven’t really grasped what makes programming hard. The real challenge of programming is how you organize a million if statements in a way that the system can be understood and evolved predictably and cheaply over time. And any tool that takes away the control of how you org…
In case you missed this thread: https://news.ycombinator.com/item?id=29442307
Re: You Can't Buy Integration
#85"Integration software products ... are not products that directly solve a business problem. ... They are programming languages, bundled with a toolchain and a runtime to support the compilation process." By this definition, Excel is a form of integration tool. A spreadsheet doesn't "directly solve a business problem". It's basically just a piece of paper with lines on it, along with some "programming formulas". A ham…
> By this definition, Excel is a form of integration tool. If you’re unlucky it’s your only integration tool. When there are no APIs, when you can’t get approval to use a tool or language, when the DBAs won’t return your calls; then export to Excel is the only integration tool you’ve got.
I think a lot of skilled software developers might be unaware of just how bad the practices can be in non-software companies regarding software development.
A few years back I remember a big corp explicitly telling me that a project for an Excel based integration between some systems would have easily got buyin and budget. Despite it being in a broader sense a crappy tool for the job due to everyone having excel installed and almost nobody being able to get approval in a reasonable amount of time for anything else to get installed it did appear to be the easiest option in the circumstances. Before this I think I was one of those people who just ruled out using Excel for integrations because I just couldn't see how it could possibly be the best option in any circumstances.
Re: You Can't Buy Integration
#86Earlier quoted context omitted.
I've worked with people of varying skill-levels but personally gravitate towards those who can code idiomatically. For me it's important I write idiomatic code and follow the language/framework/api guidelines to the letter so I don't become a maintenance burden to my team. In the fast-paced world of frontend dev, the last thing I want to do is revisit "complete" work, be it a lack of env parametrisation or something…
This is fair, but silly then to interview someone who “doesn’t know React” if you’re not willing to teach the framework. Frameworks and languages are easy to learn, idioms and all. If a candidate is knowledgeable and can write idiomatic Vue or something similar, why would you think they won’t be able to do the same with React?
I think a lot of jobs are really wanting contractors but paying job dollars.
With contractors it matters if they can code React fast today, not be up to speed in 6 weeks time
Re: You Can't Buy Integration
#87Business logic happens line by line between interfaces. Coding may be all ifs and for loops, but when it comes to implementing a new feature, having chosen carefully where to draw the line between, say, your model and your view can be the difference between a 10 line patch and a complete rewrite . If you don’t have a culture of code review then maybe the rewrite will fly, bugs and all, through to production. If howev…
The line “coding is just if statements” really annoys me. I used to think this earlier in my career. It’s technically true but it means that you haven’t really grasped what makes programming hard. The real challenge of programming is how you organize a million if statements in a way that the system can be understood and evolved predictably and cheaply over time. And any tool that takes away the control of how you org…
Re: You Can't Buy Integration
#88Earlier quoted context omitted.
I got bounced off a front-end job once, for not being good enough at React. Mind you I've been building SPA's since they weren't "a thing" and today I mostly use Vue. But for that role, they didn't like my lack of .env variables in the front-end (such as for things that end up in the HTML), after a 3 hours coding test, and a couple of minor React-y tid bits they couldn't even clarify. Basically, not "idiomatic". Mean…
TL;DR: I think you're seriously misguided. I think you're missing the point on every subject you touched on and I likely would not hire you either. For one, most frontend developers now use environment variables to feed in configuration specific data, most notably URLs and feature flags, so that they don't need to do find/replace operations in the final scripts (most notably, minified bundles). It really has nothing…
Why would one go and s/// in a minified bundle when you have the code? I don’t get it. Is your code read-only? Write-only? You can’t follow imports, can’t lookup a symbol definition?
You sound like the one who wants to hire a guy who already worked for 1-2 years in your department. These minor details at the interview like “in your whiteboarding session you didn’t name a constant like we usually do, wrong!”. Duck-diffing as it is it seems.
Re: You Can't Buy Integration
#89What are peoples’ thoughts on industry data models? These feel like integration by a different name. They often come with integration tooling as well as the core logical/physical model. That tooling is often “config not code”. And the database(s) which instantiate that data model act as the integration nexus for an organization, like a passive ESB. They become the architectural center of the organization, and the primary concern is conformance to the model (with the aim of achieving some future reusability benefit) rather than creating clean interfaces over capabilities.
Seems like all the same concerns from the article apply.
Re: You Can't Buy Integration
#90Earlier quoted context omitted.
The line “coding is just if statements” really annoys me. I used to think this earlier in my career. It’s technically true but it means that you haven’t really grasped what makes programming hard. The real challenge of programming is how you organize a million if statements in a way that the system can be understood and evolved predictably and cheaply over time. And any tool that takes away the control of how you org…
> It’s technically true but it means that you haven’t really grasped what makes programming hard. It’s roughly as useful as pointing out that constructing a skyscraper is really just applying forces to masses.
Obligatory XKCD reference: https://xkcd.com/435/