跟讀練習: Cracking the Behavioral Interview for Software Developers - 通過影片學習英語口語

選擇練習模式

每種模式都會開啟全屏練習室。

119 句

如果句子過短或過長，請點選 Edit 進行調整。

what's up guys today we're gonna be doing something a little different

but I feel like it's gonna be super helpful a lot of engineers can crush it on the technical interview

but when it comes to the behavioral part that's where a lot of people struggle

and I know candidates who did great on the technical interview

but they got a rejection

because they failed on the behavioral part they weren't able to demonstrate

that they had proficient communication skills or how well they handle certain situations

and that's what the behavioral interview gauge is for

because you can be a technical genius but

if you can't convey what you're trying to say it's going to be hard to work on a team

and I'll be the first to admit it I'm not great at just thinking of examples right on the spot

so usually how I prepare for an interview

and how well I do on it usually have a direct correlation

so before going into an interview where I know I'll be ask situational questions I'll usually brainstorm

and think of about eight to ten examples from my career that can be used to answer different styles of questions.

Anything from conflict management to a time where I made a good technical suggestion

because a lot of times you can mold your situations to what the question is asking

and what I've noticed is that the best answers usually have a story behind it.

Obviously you don't want to add too much fluff to your answer

or diverge away too far from what the question is asking

but if you can kind of paint a picture of the solution to your interviewer

that usually leads to better results

so in this video I'm gonna give myself a few prompts

and answer them as

if this were a real interview before we get into the video make sure you guys hit the like button

so I know you guys like this kind of video

and let me know in the comments if you'd like to see more

so the first question is gonna be tell me about yourself this is the question

that most behavioral interviews start with now it's important to mention that even though these are behavioral interviews,

they will still have some technical aspects to them.

So let's take a look at how I answered this question.

Hey, my name is Sam.

I'm a software engineer and I enjoy solving complex problems.

I have experience as a full stack web app developer

and I enjoy working with all layers of the stack and I enjoy building out user -friendly efficient websites.

My passion for web app development started

when I was doing my internship at AWS

and I was given a solo project to work on for the entirety of the internship

and this really gave me full ownership over everything from the design decisions to the actual coding of it

and I was also able to gain a lot of experience and exposure to different AWS cloud computing tools.

After my internship I decided that this is what I wanted to do as a career

and since then I've gained about three years of experience building

out dozens of different applications at my current company i'm helping

out with the modernization of our existing infrastructure this includes building

out new microservices as well as updating existing ones the technologies i've experienced with include dotnet for building out apis

and our server side code sql with mysql oracle and sql server as well as experience with different various javascript frameworks,

including Vue .js and Angular.

So I believe my experience and my passion would make me a great asset for your company.

So in my answer, I tried to keep it short and sweet.

I didn't get into my whole life story, even though it is a tell me about yourself.

Keep it relevant.

Don't start talking about your dog or something.

You guys think I'm joking, but I've actually heard people say that when I've been in group interviews.

And I would say a sweet spot for this question would be a minute and a half, maybe two minutes.

Again, that isn't set in stone.

These are kind of like more like guidelines, right?

Have you ever seen Pirates of the Caribbean, right?

These aren't rules.

They're more like guidelines.

All right, the next question is going to be, tell me about a time you had to persuade someone at work.

What did you do?

Let's take a look at my response.

At my previous company, our team supported 20 to 30 different web applications.

And there was really no uniformity in terms of what front -end JavaScript framework we could or should use.

So what ended up happening is we would have some apps written in Angular, some apps written in React, some written in Vue, it was kind of all over the place.

And the problem with this was, say you were assigned to write a feature in a certain app and you didn't really know that framework, you would have to at least spend time getting a basic

understanding of it before you can even start to implement that feature.

So this potentially increased the development time by a lot.

So my proposal was to just have all our apps be written in Vue .js

because it's something that I had experience with.

I thought it was fairly easy to pick up.

It's a lightweight app and it's pretty easy to inject into existing applications.

So what I did was I created a little mini demo presentation

and I set up a meeting between my team and my manager

and just demonstrated the pros and cons of using that framework.

So the result of that was my manager was on board

and we decided to use Vue .js for all our new development.

Again, that was about a minute and a half to answer it and it was told like a story.

I explained what the problem was and what I did to resolve

that problem and showed how I made a lasting positive impact to the company.

All right, the last question we're going to look at is tell me about a time you failed at work

and what did you learn from it?

So this one time I was assigned the task of implementing a new feature into one of our applications.

And we used Git as our source control, so as I was working on this feature, I was continuously pushing to our master branch, which isn't good practice

because you always want to keep your master branch deployable as well as in sync with what's in production.

Also, if we deployed this app with this feature being partially done, it would break the application.

But this was an app that barely ever got updated, so I figured I'd be all right

but of course we had an emergency bug fix

that had to be made and I was like we actually can't deploy it

because the app is gonna break luckily with source control you are able to go back

and we were able to add

that change to where I started working on the future

but in the future I learned that in order to you know

if I wasn't making any changes first create a branch off of master

and deploy to that branch and then when you're finally done with the future then merge the changes back into master.

Now a potential issue to this answer is that it assumes that the interviewer knows how Git works.

Most likely you're gonna be doing one of these interviews with another dev

so I mean they probably know how Git works but it's possible

that they don't but I think a really important thing to answering these questions is

100

that you don't want to confuse your interviewer by going too into the weeds with a particular technology

101

that they might not know.

102

So just gauge who you're interviewing with it's it's very easy to get very technical about something

103

and totally lose your interviewer and that's not good

104

because it means you weren't able to clearly communicate a technical topic

105

which is important when you're working with other devs on a team all right

106

so the takeaways from this video are keep your answers about

107

one to three minutes long the best answers usually tell a story usually there's a problem

108

or a situation and you talk about an action

109

that you took to help resolve that situation

110

and finally don't confuse your interviewer a lot of times your answers might include a very complex technical subject

111

that your interviewer isn't going to understand in a two -minute explanation

112

so just be aware of that and and even simplify your answer

113

if you need to all right guys thank you guys for watching the video

114

if you guys would like me to do another one of these uh definitely let me know

115

and if you have a specific question

116

that you want me to answer in one of these videos let me know in the comments

117

and i'll try to include it if if i end up doing another one

118

so i will see you guys in the next one.

119

And as always, keep on coding.

下載應用

流利口語所需的一切

AI 發音評分逐句打分

音標練習掌握每個音

詞彙學習建立你的詞庫

詞彙遊戲邊玩邊學

掃碼

Download on theApp Store Get it onGoogle Play

FOR YOU

本課的詞彙與口語要點

這節口語課以影片“Cracking the Behavioral Interview for Software Developers”為素材。影片中反覆出現的詞有：answer, interview, app, technical, usually。這段影片共有 119 個句子、1568 個單詞可供跟讀。講話部分時長為 7:52。說話人語速較快，每分鐘約 199 個詞，會出現較多連讀和弱讀。 83% 的單詞屬於英語最常用的 3,000 詞，其餘的詞建議在練習前先學一下。

影片中的重點詞彙

影片中 15 個值得學習的單詞，附發音和釋義：

單詞	發音	釋義
interviewer 名詞	/ˈɪntɚvjuɚ/	訪問者 /訪問者
framework 名詞	/ˈfɹeɪm.wɜːk/	骨架, 框架
deploy 動詞	/dɪˈplɔɪ/	部署
internship 名詞	/ˈɪntɜːnʃɪp/	實習 /實習
server 名詞	/ˈsɝvɚ/	伺服器 /伺服器, 伺服器
passion 名詞	/ˈpæʃən/	激情, 熱情 /熱情
demonstrate 動詞	/ˈdɛm.ənˌstɹeɪt/	論證
implement 動詞	/ˈɪmpləmənt/	實施 /實施, 執行 /執行
resolve 動詞	/ɹɪˈzɑlv/	解決 /解決
stack 名詞	/stæk/	堆
gauge 名詞	/ˈɡeɪd͡ʒ/	標準尺寸 /標準尺寸, 標準規格 /標準規格
confuse 動詞	/kənˈfjuːz/	讓……困惑 /讓……困惑
assign 動詞	/əˈsaɪn/	分配, 分派
topic 名詞	/ˈtɑpɪk/	主題 /主題, 話題 /話題
proposal 名詞	/pɹəˈpoʊzəl/	提議 /提議, 建議 /建議

影片中出現的短語動詞

單詞	釋義
end up 動詞	到達
go back 動詞	回去, 返回
pick up 動詞	拾取, 撿 /撿

值得反覆跟讀的句子

影片中簡短而完整的句子，可以直接用在日常對話裡：

Don't start talking about your dog or something.
What did you do?
Let's take a look at my response.

影片中的語法

說話人最常用的結構，並附上影片中的原話：

結構	影片中的用法
被動語態 be + 過去分詞 — 強調發生了什麼，而不是誰做的	was given · isn't set · were assigned
現在完成時 have/has + 過去分詞 — 過去發生但與現在仍有關聯的事	I've noticed · I've gained · i've experienced

需要注意的發音

說話人用了 46 次縮略和弱讀形式，例如 gonna, don't, I'm。請按聽到的簡短形式來說。

“sh” 和 “zh” 音: internship /ˈɪntɜːnʃɪp/, passion /ˈpæʃən/, explanation /ˌɛkspləˈneɪʃən/, exposure /ɪkˈspəʊ.ʒə(ɹ)/, efficient /ɪˈfɪʃənt/
長單詞——注意重音位置: behavioral /bɪˈheɪvjəɹəl/, infrastructure /ˈɪnfɹəˌstɹʌkt͡ʃə/, explanation /ˌɛkspləˈneɪʃən/, potentially /pəˈtɛnʃ(ə)li/, communicate /kəˈmjuːnɪkeɪt/

中文母語者容易讀錯的音：

/v/ — 不要讀成 /w/，上齒輕觸下唇: interviewer /ˈɪntɚvjuɚ/, behavioral /bɪˈheɪvjəɹəl/, server /ˈsɝvɚ/, resolve /ɹɪˈzɑlv/, solve /sɒlv/
詞尾子音 — 要讀清楚，後面不要加母音: framework /ˈfɹeɪm.wɜːk/, internship /ˈɪntɜːnʃɪp/, demonstrate /ˈdɛm.ənˌstɹeɪt/, implement /ˈɪmpləmənt/, resolve /ɹɪˈzɑlv/
/r/ 和 /l/ 的區別: behavioral /bɪˈheɪvjəɹəl/, resolve /ɹɪˈzɑlv/, proposal /pɹəˈpoʊzəl/, partially /ˈpɑɹʃəli/, correlation /ˌkɔɹ.əˈleɪ.ʃən/

如何用這段影片練習

先完整聽一遍影片，不要開口，記下不認識的單詞。
先用 0.75 倍速逐句跟讀，熟練之後再回到正常速度。
錄下自己的聲音並與原聲對比，特別注意 interviewer, framework, deploy 這類單詞。

什麼是跟讀法？

跟讀法 (Shadowing) 是一種有科學依據的語言學習技巧，最初開發用於專業口譯員的培訓，並由多語言者Alexander Arguelles博士普及。這個方法簡單而強大：您在聽英語母語原聲的同時立即大聲重複——就像是一個延遲1-2秒緊跟說話者的影子。與被動聽力或語法練習不同，跟讀法強迫您的大腦和口腔肌肉同時處理並模模擬實的講話模式。研究表明它能顯著提高發音準確性，語調，節奏，連讀，聽力理解和口語流利度——使其成為雅思口語備考和真實英語交流最有效的方法之一。

影子跟讀法: 閱讀完整分步指南 →

跟讀練習: Cracking the Behavioral Interview for Software Developers - 通過影片學習英語口語

選擇練習模式

下載應用

推薦影片

Answering behavioral interview questions is shockingly uncomplicated

FULL Data Science Mock Interview | SQL, Statistics, Business

Describe a Job Interview You Had | IELTS Speaking Part 2 & 3 | Band 9 Vocabulary | Learnivo #ielts

The Essential UX Interview Questions (And How To Answer Them!)

How To Dominate 2026 as a Software Developer

The unfair way I got good at Leetcode

How To Introduce Yourself as a Software Engineer: Tell Me About Yourself!

AI (Artificial Intelligence) JOB INTERVIEW QUESTIONS & ANSWERS! (How to PASS an AI JOB INTERVIEW!)

How To Answer Data Analyst Interview Questions to Get a Job

Google product manager behavioral interview (Top 5 questions)

Why Are You a Good Fit for this Role - How to Answer

Interview Tips from a Senior Software Engineer... and a 4 year old