Reading this article inspired me to raise some questions to the developers community.
In case you don't want to read the post, the writer, Anton F...
For further actions, you may consider blocking this person and/or reporting abuse
I've been asked similar questions and I think they have some merit and are actually useful if asked for the right reasons. Here are some thoughts:
To draw a parallelism with another profession, if you're in the business of making windows, you probably don't need to be an expert in metal foundry and glass blowing, but you should know that materials expand with heat and make sure that your windows can still be opened during summer (hint, not all of them appear to know that).
In summary, many interviews suck, and an interviewer can make this question suck, but I don't think that the problem lies in the question itself.
Yes, this absolutely. It's a measurement of behavior and thought process (as much as these things can be measured) not how many details and facts you were lucky enough to have already learned.
I loved @antonfrattaroli 's post, but that same question was the first one I was ever asked in a technical interview for a job I didn't get and I still feel pretty salty about it. I didn't have a good answer but I would have still been great for the job. Basically how I feel about several failed technical interviews early on.
Same here.
Few weeks ago I tried to get vetted at a freelancer platform and they did two interviews and a test project to check if I could really programm, haha. This was the first interview process in my life that asked valid questions for soft skills and technical skills and had a test project that made sense to me.
Most interviews were either done by people who didn't know what to ask OR how the answers should look like, they just hired me based on a gut feel I guess.
And a few were some strange processes that asked basic computer science stuff and required me to implement strange projects that had nothing to do with the job. I always failed and I'm still salty about them :/
I was asked something similar years ago. He said "I open a website in my browser, turn around and talk to my wife, and when I turn back the page has changed, what could have happened?"
I thought he was looking for something specific, so I started guessing, and it started making me angry, and I'm usually pretty grounded. It ended with me saying "I don't know what you're fishing for, I've given you like 8 possibilities already."
But he was a really good interviewer - unfortunately I was too inexperienced to appreciate it.
My experience was part of what, in hindsight, was still a really bad interview. The person who asked me that question was a manager basically reading off a sheet of questions and the next step was with a dev who's only real concern was whether I'd "annoy" them once I got the job.
I'm sitting here just shaking my head at the memory.
I once offended an HR manager, by asking them "are you gonna ask me about the principles of OOP?", and apparently he was, because he was shocked and told me why shouldn't he, and I said "You invited me to a Senior PHP Developer position, surely I would know the OOP principles by now!".
Well, I didn't mean to offend them, and might have come as arrogant to them for saying what I said... Oh well...
The browser was an unpatched IE 6 with a litany of vulnerabilities including one that allowed ActiveX controls full system access with admin rights. There happened to be an embedded ActiveX control in the page you opened that downloaded an exe and launched it. The exe then went through the file system looking for adult content on the machine, generated an html page containing all of that content, and launched the page in the default browser: IE 6.
Lol, I did not think of that one.
But
/etc/hostshas nothing to do with DNS. Yes, they are both related to host name resolving, but so is NetBIOS.Why should I know that I first ask the known root DNS about which server knows about
.tld, then use the returnedNSrecords to contact the next DNS server about a name server forexample.tldso that I can ask that server whatwww.example.tldis, only to get told it is aCNAMEso I have to do the same thing until I finally get a hold on anArecord.They are looking for a back-end developer working on standard business logic. Not for a network engineer or a developer writing a DNS client or server.
Oh wait... we did not even reach the DNS part yet, we are first going to through the OS's name resolving. Maybe messed up the
resolv.confornsswitch.conf. We're also supposed to be system admins.So how about that multi threaded weighted graph exploration algorithm...
We work in an unregulated industry where information is only proven by other "experts" in the fields (usually a team member or consultant).
Electricians, plumbers, architects -- all have to get licensed by the local government to operate their business. Why? Because as a society we understand that the quality of their job impacts the wellbeing of real people. If a house isn't built properly, someone can get hurt.
But when it comes to creating applications for people, particularly ones that engage with a certain level of a user's privacy or information, developers aren't required by law to get certified by their local government (or even a larger governing body for developers).
This lack of standard for licensing causes fissures in the professional development community. Who do I trust with my application code? The guy who says he took a bootcamp, or the one who says he's an expert in React. It all has to be proven, either by a fellow expert observing the professional produce the code in person, or by probing the professional with known issues concerning the topic.
It's similar in the art world, where everyone has different backgrounds and methodologies for accomplishing tasks. Someone may know how to use Photoshop or Illustrator, but may not have experience actually physically printing their work -- which would be somewhat necessary for a position like "Head of Printing".
Obviously some developers take this to an extreme when they require seemingly unnecessary knowledge for the position. There's a line between what I need to know, and what an elitist things I should know. Or really, it lets me know how truly broad the job description is -- and that as a Senior React Engineer, I'll probably be doing devops too 😜
The difference, is that you don’t ask a plumber to build a swing for 20 people (hey, why not? He knows his tubes !?!), or even an “electrician” to build a MHD flying saucer (after all, it’s just wires with current and tension).
But in the case of a software developper, you will ask him to build anything, impacting from the smallest data item (a few bits in a processor) to the whole world! Now people complain that bitcoin miners contribute to the climate change!
So yes, a software developper has the moral obligaton to know more than just a programming langage (I would hire somebody giving a good answer the that interview questions, even if he knew no programming language (as long as he can still do the fizzbuzz program in pseudo code)).
It can't all be observable distributed event-sourced machine learning NoSQL blockchains all the time. There're boring parts, or rather there are parts you personally may not be interested in, but most of the domain knowledge and practical considerations you mentioned are rather important to the modern practice of software development.
You seem to have a particular antipathy for networking; it's about my least favorite area as well, but I work on systems that communicate across networks -- as do you the instant a database or REST API is involved -- so an understanding of the basic principles and a familiarity with common patterns, tasks, and trouble spots is immensely useful in my capacity as a developer. This is how I can venture the slightest bit outside my comfort zone without becoming stuck immediately. At a certain skill level we're supposed to know the fundamentals of this stuff, or to have the grounding to be able to research and come up to speed quickly, because without that broader foundational knowledge we are worse at applying that skill.
And as for tooling: understanding your operating system, shell commands, scripting languages, and even hardware makes you a more effective operator of a computing machine! Not everyone has the time or inclination to really dig in but there is incontestable practical value to it!
Sometimes interviewers ask questions to probe your breadth of knowledge. If I asked this question of an entry level candidate, they would rank up a notch if they were able to make a serviceable answer. But being unable to answer would not disqualify them, since entry level is not required to already know this.
Breadth of understanding is very valuable... if you don't consider how your software affects others (users, IT, budgets, etc), you are not going to make very good software. Entry level devs are given a narrow scope and allowed to be somewhat ignorant of these things in the beginning. But they should not stay that way.
Because the knowledge is relevant and critical. It's OK not to have learned these things. It's not OK to refuse to learn things vital to the job. Without core knowledge of the software environment, how the data is delivered and rendered from server to client, an internet software developer is unequipped to make good design decisions -- blindly unaware of what problems are being introduced or why.
I hate this process and agree with your sentiment. However, it is necessary.
It gives you an opportunity to drill into someone's mind and uncover their capabilities. Anything and everything can be put on a resume. You could have watched a video tutorial on a topic and know enough about it to bullshit your way through it, but that doesn't mean you can actually apply it effectively.
When hiring an engineer, I want to test that engineer's breadth and depth of knowledge. Everything on their resume is fair game. In addition, most jobs are not constrained to just coding simple stuff. You run into unforeseen issues. I want to know that the engineer is not going to simply rely on StackOverflow or google their way through it and copy/paste stuff.
Without that level of knowledge, you won't be hired by Google or Microsoft or Facebook. These companies have a business to run. They need self-starters who can work autonomously and come up with novel solutions. That doesn't happen if your breadth of knowledge is narrow.
If you're good at PHP, you can build a good website, but you won't be able to build a large-scale distributed system that can support 12,000 requests per second. However, your knowledge about networks, hardware and various components in the pipeline will allow you to build such a system effectively.
I agree with you, Nick. If you wanna check how an applicant thinks, you are on the right track. Testing an applicant's ability to solve problems or their ability to design a complex architecture that corresponds to your business demands is 100% justified.
What I am talking about is to standardize the interview process for software developers, so developers know what is expected from them to know.
Today, we have chaos. Each company has its own standard: in one company, they ask memory base questions which you need to answer in few seconds, in another company, they give you a 4 hour task before you say hello to them, in another company, they ask you about simple things and if you fail to answer one of them questions, they end up considering you "below the demanded level" although you have 10+ experience in many other companies.
(I can always ask you a SIMPLE question to which the answer you might have forgot..)
One more thing about your last point (paragraph), I learned all what I know on the job. I was accepted as an intern, then I got promoted all the way to senior in about 4-5 years. You would agree as well that a GOOD developer is one that "learns on demand". We are humans after all, we are not memory machines. I bet you forgot lots of things that you have learned just 1 year ago. We forget the code that we write, don't we? We forget code because we write lots of code, and we forget knowledge because we already know too much of it.
Someone, someday, will figure it out. They will figure out how to shape up a fair job interview for both the company and the applicant. All I want is to contribute to that.
I'm with you on that. I forget stuff all the time. Sometimes I feel like I am developing Alzheimer's with the amount of stuff I can't recall. However, one thing I've noticed is that my fundamentals are still very strong. I don't do well on interviews if I go in cold without brushing up on stuff. And, it sucks to have to learn everything all over starting from my first CS course - (I've been coding professionally for 20 years now!).
I have preferred project based interviews as they are more realistic. However, those are a bit tricky as you may not be able to gauge everything. On few of my recent startups, I paid candidates to work on a problem that was relevant to the business. I liked that approach as both sides were gaining something and nobody was taken advantage of. Also, if it turned out relatively well, I was able to use their code.
I don't think Software Engineering can be compared to other professions. What we do is pretty unique and things change daily in our field which is important to be on top of if you want to stay competitive. The scope of work for most of the other professions is fairly limited, so I think the interviews can be standardized there. In the 90's and 00's, certification was a big thing, but I think that has sort of phased out.
You are right that we should be learning-on-demand, but one can do that only if they have strong fundamentals. Traditionally, this was evaluated through your transcripts and GPA, but that is not a good metric. So, how else can we evaluate a candidate in 30-60 minutes?
Anyway, I like the discussion on this thread. Thanks for starting it.
I also prefer home based tasks/projects, but they don't usually pay around here..
Fundamentals are a must know, I agree totally, the rest should be "need to know".
I've been doing this for 5 years and I already feel like I got a bad case of the Alzheimer's , I cannot imagine what would happen after 20 years!!!
I hope you'll keep on posting on Youtube, I just started following you there. Very interesting stuff, especially that I just started focusing on React.
Thanks! Let me know if there's a particular topic you'd like to learn about.
Once a company had me work on a distributed cloud storage (like dropbox) that encrypted files into 96 chunks which were stored across the web on 96 different machines with redundancies. The idea was that you give some space on your machine to get some space on the cloud (aka other people's machines). They said to do my best work and take as long as I want - it took me 3 weeks to deliver something that was production ready. They loved the project and called me in only to say that oh we don't have that role anymore, instead they made an offer for an SDET role. I'm glad that place went out of business recently!
I've worked with people who've been in the industry for over 40-50 years and they're definitely a huge inspiration, so I think there's hope for us. :D
Well, I am fairly new at React, so just about anything is interesting to me.
One little thing I would ask for is that in your React video, we could hear you type kind of loudly. If you can push away your microphone from your keyboard, I think the viewers would really appreciate it :)
Thanks for the feedback. I will need to figure this out. I had increased the gain on my mic since last time I got feedback that my voice was a bit low. The keyboard on my macbook is also a bit loud with the force feedback. I might need to consider typing in chunks and turning off the sound and introduce background music (but that'll work only in large chunks, not every 10 seconds :D).
But we haven't event started at the beginning yet.
It is unclear if an USB keyboard was used or a PS/2 keyboard. Because they are fundamentally different. In case of a PS/2 keyboard we are creating interrupts to which the computer must react right away. The USB keyboard is polled of pressed keys every ... etc. etc.
Is this really relevant? It isn't. This is the whole point of robencom's question. It is not really normal to expect developers to know everything related to computers. Where does it end.
Just knowing the language is not enough. It is not even that important. Knowing the principles on which the language is build is more important. Languages change. Choice of language can change. The principles do not change that much.
I'm glad you got the point, Michiel.
As you said, the principles, the FOUNDATION of Development really doesn't change much, it is the same for any language really.
Interviews should test the ESSENCE of a developer, their ability to use their brains to solve problems. Interviews shouldn't consist of trivial or random questions about our field.
While I understand and do believe it's important to understand some things about computer science in general, to think that someone pretty much can't be a good developer if they don't know those things, then you're flat out depriving yourself of some really good developers. Some of the best developers I know couldn't explain that stuff to you yet I know they can make a damn good app that runs fluid and has a lot of optimizations. But because they don't know all the low level stuff of DNS they should not be hired? Who ever thought of this for developers is part of the big issue developers face right now in interviews.
I will admit I do ask "open ended" questions sometimes just to see how you think. No right or wrong answer. It also doesn't make or break an interview. I'm just interested in seeing how they "think" how they might go about thinking of a solution.
But in general, if I'm not interviewing for a job that is super network or low level code intensive, then asking me low level computer questions is flat out a waste of time. Cool they know how a DNS server works. But can they actually solve that issue of needing another React Expert? Answering that question doesn't tell you any of that.
I'm a little bit infamous for playing devil's advocate on this topic around here, but I think it's worth pointing out: a developer whose work touches seven topics had better know enough about those seven topics to not be a liability. Most of the worst blunders in computer history were because some developer didn't understand their client.
That is not to say that we should be experts, but there is a balance. Software that works over the network needs a developer with a working knowledge of networking. Air Traffic Control software must be written by someone who knows how ATC works. Software for scientific-calibre light microscopy requires the developer to be comfortable with the concepts and terms in light microscopy. Accounting software should be written by developers who have a working understanding of accounting. And the list goes on.
One might say, "Baloney! That's the client's job!" But if we're honest, because we're the programming experts, it's our job to know what the client needs in the software when they don't. We need to inform their choices, and they ours. If that's missing, terrible software results.
Now, stepping back from that, is there a problem with HR departments expecting developers to know everything about everything? Yup. Can that improve? Yup.
Yet, between the two standpoints, we also have to consider: how certain are we that those questions were the deciding factor in our not getting particular jobs? HR rarely tells us candidates anything. It could well be that we were the second or third choice on the list, but some other guy had valuable related experience that we didn't.
I don't know that the question is asking what you think it's asking. It's a complex and deep subject, and certainly not many people, if anyone, can answer it exactly. Knowing just a little bit, though, can you REASON how it works? If you don't know anything about it, could you develop a rudimentary algorithm that would accomplish the goal? It's a critical thinking question. Knowing a language isn't development. Development is taking complex problems and breaking them down into smaller and simpler problems with help of a language. This is a great question to see if you can do that, especially if you don't actually know how it really works. If you can't use your native speaking language to express a complex idea, why would I think you could do it in a programming language?
Software doesn't exist in a vacuum. It runs on an operating system, that sits on hardware, that utilizes a network and each piece of the puzzle inserts variables that will impact the software you wrote.
The classic interview question "what happens when you type google.com in your browser?" I think is a fantastic question, and everybody should be able to answer it at some level.
Without understanding where and how your software runs then the only answer to "It's not working in prod" will be "well... it works on my machine".
You know, I was watching a video(youtube.com/watch?v=Wx3WlQLFa3w&t=...) about Security the other day, and one thing that really caught my attention was the speaker saying:
"thinking you can create a secure platform to host your application when you are not a security expert is like thinking you can represent yourself in court when you are not a lawyer."
Security should be one of the biggest concerns for any developer, but yet we are all "wannabe security experts" as developers.
OS? Do we even dare to claim that we understand how the OS handle things?
Network? Who is a CISCO certified engineer? I know few, but they aren't developers.
WE might know a thing or two or three. Some of us are more hardcore, they really dive into one of those topics. But you guys cannot hold it against other developers who don't know how the DNS works or so on, because you didn't know as well at some point, you only learned about it when you NEEDED to, and you probably forgot about it by now. And there is a TON of things you don't know about OS or Networks or or or... Maybe, there's a ton of things you don't even know about that one language that you think you already mastered.
Developers want to believe they know everything. Let's face it, we don't have the brainpower to memorize it all. You learn a new thing today, you forget something you learned 100 days ago. Knowledge comes and goes, your essence as a problem solver evolves with time. That's the real you. That's your identity as a human and as a developer.
There are a lot of strange questions posed during developer interviews.
They usually fall into one of the following categories:
-Exploring how the candidate parses/tackles a problem
-Determining depth and breadth of the candidates peripheral knowledge
So when we were last hiring for a developer, I posed questions about sorting and memory use, as well as a ridiculous question about performing an algorithm in assembly. We don't use assembly, and the language we use handles memory allocation in the background. The purpose of those questions wasn't to see if they knew assembly, or if they can crank out sorting algorithms. The assembly question lets me see what they do when they're confronted with a problem that "looks scary". The sorting question lets me see if they know enough about computing and memory allocation to make wise choices when designing their own methods for handling our data.
Any professional should know how their tools work. A race car driver might not be able to bore out his own engine, but he should know about gear ratios and compression. A hunter should have a rudimentary understanding of rifling. As programmers, it behooves us to understand how computers work, the fundamentals of networking (since few computers are used sans networking these days), the fundamentals of how an OS works, and if you're a web dev, since the users' entire experience occurs in a browser -- how information is exchanged between the client (browser) and the server.
Actually it’s a fundamental question I’ve been asked this question and i also ask it a lot in interviews.
The key concept is to uncover your curiosity and passion, not to give a perfect answer. It’s also not meant to be a make or break question. I see it more as a conversation starter.
That said I’m bothered by companies who still ask for a personality test to determine “culture fit”. I’ve built great tech teams and culture without weird tests.
Tech recruiting is hard but it takes an empathetic nd knowledgable tech lead to identify great talent.
The Enter key pushes back against your finger with an equal and opposite force.
A few thoughts come to mind.
For some reason, developers are lumped into the 'professional' category (doctors, lawyers, and so on), even though really it's more of a trade job. Most 'professional' workers are licensed in some way, and getting that license involves some (often) very intense examinations. Devs aren't licensed, but companies want to treat them like they are, and so lay on the complex grilling during interviews.
Also, there are a lot of devs, and we keep cranking out more. (With more to come due to all the silly 'everyone should code' programs so beloved in lower ed right now.) If you have 50 applicants for a job, it isn't a lot of extra effort on the company's part to weed out the wannabes with a series of increasingly difficult interviews. We used to call this 'purple squirrel' syndrome...with so many applicants, the company writes extraordinarily precise job descriptions and test against them. (With so many applicants, there's bound to be one or two purple squirrels who match.)
I personally think that the process is ridiculous, and that companies use it because they are lazy and haven't bothered to come up with a better model for finding compatible workers. Much more important than any specific skill is the ability to learn and adapt. Heck, if I were still conducting interviews I might hand an applicant a small set of docs for a made-up language and ask them to write code in it to solve some problem.
Even more important, really, is whether someone is a good fit for the team in terms of they personality and work ethic. You're going to be seeing this person every day for hours at a time and have to rely on him or her to carry their weight...all the skills in the world don't count as much as whether I can stand to see you walk in the door in the morning.
In this talks I distinctly make the difference between the 2 terms, its easier to explain
Programmer Writes code, in abstract thinking it only goes up to a system level, maybe entire software level.
Developer Beside being a programmer, it is responsible for that code to work in production. This means a sh** load of things: deployment, monitoring, performance, environments .........
So yeah, if you are a web developer you must understand what these are: CDN, DNS, browsers, cache, storages, latency, availability, security and many other things, because they have a direct impact of your product and user experience.
Real example, last week: me explaining to a front junior end developer what types of Storages it has to know (cookies, localStorage, sessionStorage, indexDB, local files cache). His response was "it is not my job no? This sounds like server guys stuff". Of course a "React developer" only knows how to make a view button, but if you want to improve the performance you have to cache stuff, so again. Programmer vs Developer.
Yeah, ultimately, as a developer, you often DO end up a dentist asked to do heart surgery. (Which was, like, actually halfway a thing in the 1800's, right?)
It all depends on perspective. Your reference group for difficult job interviews is presumably big tech firms like Amazon, Google, FB, etc and probably some well funded startups. And surely they are putting everyone through the ringer because these firms have become a status symbol type of job. Think of something like college admission into the Ivy League: they do this because they can.
Dig deeper into the tech landscape and I wager you'll find exactly the opposite. Most hiring managers for large, non-tech corporations, non-profits, government, etc don't even know how to construct the job descriptions. I've seen jobs asking for 8-10 years of React experience ;) If you're savvy, you're likely the most technically capable person in the room for these interviews.
I guess our job titles haven't matured the same way as our profession has. I mean we have lots of job titles besides "developer", like "programmer", "architect", "(site reliability) engineer", "devops expert", " ninja", you name it. But every company seems to have their own profile and requirements for these titles. There's definitely a lack of standardisation, which leads to frustration based on different assumptions.
In the end the title "developer" is what most of us are fine with - the generalists as well as the specialists.
Since there is the notion that software developers also need to know the basics, I'd like to contrast this to a real-world equivalent.
Imagine I have a plumbing problem, and am looking for a decent plumber to take care of it. To get some idea of their knowledge and understanding, I ask them what water does when it goes into the pipe. Regardless of the academic background of the plumber, should their answer relate to the ideal gas law, should they be explaining Poiseuille’s law or would Bernoulli's principle suffice, or are they better of explaining the stochastic effects of thermodynamics as it relates to small polar molecules?
That's not to say that the basics are never helpful, but people tend to get more work done if they apply deferred execution to their learning: if I need to know about thermodynamics, I'll study up on it. Until then I can perfectly do my job by knowing that for these situations a brand X plastic pipe will do and for those situations a brand Y metal pipe will be necessary.
In fact, being able to apply deferred execution (to both learning and problem solving) is a vital skill, if you're to avoid being bogged down in yak stacks. This also very closely relates to being able to solve problems through abstraction, which is an actual basic skill for developers.
Because developers are usually paid more than teachers, painters, mechanics.
It would sound like a sensible response, but it doesn't apply to lawyers, surgeons... Not even players... So, no. Don't think it's directly related to the paycheck.
Not directly, but there's some truth in there. I still feel that developers usually are seen as It guys and are expected to solve every computer problem out there regardless what it is. So like always, it's not that simple.
That is also true. Like in any highly specialized job, there is a lot of ignorance with people who are not familiar with it and it so happens that more often than not, those are the very people who interview candidates for the position.
Why is this even an interview question for a DEVELOPER?To test your basic knowledge, and how you think if you don't know the specifics. I would say that for a frontend, at least knowing about
HTTPwould be the minimum. For a backend, making the link betweenDNS, thenHTTPthenHTTPSwill be considered correct. How you fill the rest will tell you on how you think.WHY is it when it comes to DEVELOPERS, we are supposed to know NETWORKING, OS shell/bash/commands, other languages, the WEB, the INTERNET, COMPUTER HARDWARE etc..? I believe, as developers, we are required to know our language (PHP, Java, Python..)That I would disagree. A programming language is just a tool in the stack. Everything you do as a developer is solving problems, by taking input and producing outputs. So "communication" is way more important than the language. Algorithms too. If you have your algorithm written in C++, then switching to Java and PHP is a few Google Search away. You could train yourself to know all the PHP API from A to Z, it would not make you a better programmer if you don't know what infrastructure will run your code and for what purposes.
For a web developer, HTML/CSS/JavaScript is a must.I was a web developer for 8 years, project manager for 3 and little I know about CSS. It was usually the digital graphist designer who transform their photoshop maquette into CSS code at least 3 times faster than any programmer I know.
But beyond those, I really don't see why a PHP developer would stuff their head with Networking or OS specific info.For instance, web developer often develops on Windows but their code is hosted in Linux. Linux has a case-sensitive file name scheme, but Windows doesn't (try to create a file named hi.txt and Hi.txt in the same folder). It can impact you PHP includes, but also if you try (you shouldn't) export your MySQL database from Windows to Linux.
Often, dev environments are different than production. I saw a bug where our clustering tool for MariaDB didn't work with MyISAM and one table hadn't popped up at peer review, half the data was displayed for each refresh.
For backend developer, knowing about proxy/reverse-proxy can help you dodge backend to backend API calls.
And with containerization, your solutions should be shifting towards their premises: a container should run a simple process doing one thing easily, independent, immutable, etc. That would have a great impact on your way to develop your solution.
That is just the tip of the iceberg.
Surely, knowing more is better, but I don't think it makes you better developer than someone who REALLY understands PHP.Yes, I believe it does, since when you will be confronted on a bug that does comes from your communication protocol, OS-stack, and stuff, knowing how it works will help you find it faster.
I cannot say how MAD I was when I was asked to do so and how HAPPYYYY I was when i did it!I was exactly like that when I started, I didn't like to depend on software other people had created. When it bugged, I would say to myself "How hard it would have been to make it like this instead???". But then I realized I couldn't do everything and open my mind to the world.
Ask us about what we love to do, what we learned and did for thousands of hours. Don't ask us about the few hours we spent reading an article about NetworkingI agree with the fact that you should work in a place you will like to work. Don't take a job that will ask you to do stuff you don't like. Don't forget that they are searching for someone as much as you are searching for a job. If the job doesn't fit your needs, just don't take it.
We are ADAPTABLE bunch, us the developers. We can do almost anything!That is also true: I always say that a developer that don't like change will have a hard time in his or her life.
On a final note, my most stressful interview (even though I got the job) was for a teacher position for Web Development at a college (I'm in Québec so it is called Cégep, it is just before University). Questions like
What do you do if you are proven wrong?, followed byGreat, but now everybody is talking and laughing and not listening to you. All of that in front of 5 interviewers.I disagree. You should not only know your own language and frameworks but you should also know at least one or two languages from different paradigms. For example, in 2018, you should know at least a functional language, a reactive language / framework and a procedural language, hopefully with a parallel framework as well. This gives you more insight into the different possibilities when looking for solutions.
If I only have a hammer, everything looks like a nail ...
Similarly, you should not only be fluent in your domain but in several others, e.g. front-end, microservices, web services/SOA, relational database, non-relational database and yes, networking. You should probably add several common services such as SOLR/Elastic Serach, TensorFlow, ... as well.
There are many reasons why such 'full-stack' developers are more valuable, the start with app architecture, security, performance and extend through devops and deployment concerns.
Yes, it's harder but it's no different from a building contractor having to know about HVAC, electrical, plumbing, roofing, masonry, carpentry and even landscaping.
What is happening in the UK is roles are asking for an increased range of skills, which can never get used in the role. To cover that many technologies would result in nothing of quality getting delivered.
The truth is, people are greedy. They want their hires to have all these skills and then some.
I happen to have BI, server side and Web development - but draw the line at chasing more technologies just because employers claim to want them. So, I will learn svelte at some point, but avoid angular. I doubt I will learn power bi but, may learn sap hana. Doing so puts them on the back foot because you have skills they don't.
Sometimes I think it is less about the actual answer as much as it is about how you demonstrate your thought process.
Suggest to detail the difference of a software engineer and just a developer
This is my second read, and the paragraph contains "what happens when you type google.com.. " still made me laugh. Good and honest article
Whenever I have tough intrrviews I always remind myself that this is the easy part. The real tough part is the job itself. I can't even compare the complexity.
Thanks for sharing this important information with us.
also practice more Tough Interview Questions and Answers.
Am I the only one who would have answered you browse to Google's home page? :P