I'm going to lead with a particular example. Everyone probably understand the value of code testing, though I haven't seen it in my personal experience, to see fellow developers at work writing their own tests. I've been with five companies and they all follow a QA-focused process.<p>What we typically do is mark an issue on our project tracker (Redbooth, for example) as something like "send to QA", wait for the lead developer to push to the staging server, which can take a while because the lead dev is usually outsourced and living in a very different time zone. When he finally pushes the code, QA is able to test the new code to see if the issues have been fixed.<p>As the developer I'm not expected to write my own tests there. I don't know what regression means (is that like linear regression?) and wouldn't know which testing framework to use. However, more and more, I have been interviewing with companies that prefer automated testing and developers writing their own tests.<p>They might ask me what my experience with unit testing is, my mind draws a blank and simply say I have no experience with it. I'm sure that's a turn-off for them and now probably see me as a rogue who plays by his own rules, wreaking a tornado of havoc onto well-structured code. Anyways, I want don't want things like a lack of automated testing experience to be an "anti-selling point" anymore. But the companies I worked at didn't have a business case justifying why they should spend expensive developer resources that detracts from something that just works already.<p>"I don't know X but I will have no problem learning it!!" is also not the saving grace at an interview like some people think it does. There has been no instance of me saying I can pick up new knowledge quickly in an interview in which the company gave me an offer. It's getting to the point where now I have to sell businesses cases to remain employable for other companies. Anyone help me out with this, starting with this particular example with TDD?
Here's what I would do:<p>1. Spend a couple of hours doing some research. So you'll learn "regression test" means "automated test to ensure a bug is fixed and doesn't reoccur", and about some automated testing frameworks for your language of choice.<p>2. Spend another hour doing some minimal automated testing with one of those libraries.<p>3. In interview when asked about testing you explain "At my previous employer we mostly focused on manual testing, so I did that, and then QA person checked it and usually my manual testing was good enough, so I'm pretty thorough. But I know automated testing is important so I've spent some time looking into it, and I'd probably be using <testing framework you found in step 1> for <your language>."<p>Basically:<p>1. Don't lie.<p>2. Spend small amount of time to make sure you have basic albeit superficial knowledge, which is a <i>lot</i> better than "dunno".<p>3. Communicate you can learn on your own.<p>4. Communicate you care about quality.<p>Some general advice for interviewing for jobs with technologies you don't know: <a href="https://codewithoutrules.com/2018/01/23/job-with-technology-you-dont-know/" rel="nofollow">https://codewithoutrules.com/2018/01/23/job-with-technology-...</a>
First, framing: obviously, every company would <i>love</i> to hire candidates who are proven experts in <i>their</i> methodology and <i>their</i> technology and <i>their</i> industry. But it's just as obvious that this isn't possible. So hiring involves compromise. You don't need to get every question "right" in order to be a winning candidate.<p>Second, as itamarst said: always be honest, but also be curious. If you're consistently seeing something come up in ads or interviews for the places you want to work, dedicate the time to research it thoroughly and earnestly. You can't invent experience, but you can demonstrate enthusiasm and preparedness.<p>Third, fulfill the compromise: look for jobs where you're already a very good fit for other details like familiarity with their industry or with a particular solution. The more you stand out by some measures, the more leeway they'll afford you for others.
So do you know what unit test means? You said at the interview you could learn it, so have you?<p>At interviews I loved asking a question I did not expect someone to know, but they would feel embarrassed by not knowing:<p>You know what trees are? <of course><p>You know what binary tree are? <of course> Please explain...<p>Do you know what a 2-3 tree is? <usually not, so I explain><p>You know what a balances tree is? <yes><p>You know what a B tree is? <yes><p>What is the difference between a Balanced tree and a B tree? <silence> Ok so this seems like a technical question right? Wrong. There are several possible answers:<p>1) I have no clue (this is acceptable)<p>2) say something (I will write down every word you say, after the interview I will look it up, because even I cannot remember the answer. If you are right, then good for you, this question counts no more than answer #1, if you are wrong, depending on how wrong, you might be eliminated. I do not need someone who feels such a need to be an expert that they make up stuff)<p>3) I do not know but I know how to find the answer. (this is really what I am looking for. You will not know everything but should be able to work stuff out. But that only gets you 0.5 points. You must look up the information and email me the answer. 24 hours is as good as 10 minutes after the interview. Although I hate it, it should be in the stupid thank you note.<p>For any skill you do not have but you understand it, try and relate it to something you already have been doing.
IMHO, not understanding testing is a very big hole. It is not like not knowing what the latest and greatest Node.js web framework is. An interviewer could quite reasonably eliminate someone by not having worked with testing before. Your best bet is to learn about testing well enough to eliminate this hole.