10个重要的面试问题 *
最好的全栈开发人员可以回答的全部基本问题. 在我们社区的推动下,我们鼓励专家提交问题并提供反馈.
现在就雇佣一名顶级全栈开发人员Interview Questions
这个问题的目的是测试应试者对RESTful API标准的了解程度. 构建端点时的一个常见错误是在路径中使用描述性动词. For example:
GET /users/search
GET /posts/create
Instead, 真正的RESTful路径应该只包含名词——端点上使用的方法应该决定操作. For example:
-
POST /users
(create a user model) -
PUT /users/{id|slug}
(replace a user model) -
PATCH /users/{id|slug}
(update part of a user model) -
DELETE /users/{id|slug}
(delete a user model) -
GET /users/{id|slug}
(retrieve a user model)
确定资源是否存在是api中经常需要的操作, 但很少按照RESTful和行业标准正确地完成. 确定资源是否存在的常用方法, 以上面的“user”资源为例, is like so:
HEAD /users/{id|slug}
此请求将使用最少的带宽,因为它将不返回任何数据,仅返回一个 200
(resource exists) or 404
(资源不存在)HTTP状态.
考虑下面的数据库表设计:
CREATE TABLE `notifications` (
' id ' INT NOT NULL AUTO_INCREMENT;
`type` INT(8) NOT NULL,
' notifiable_id ' INT unsigned NOT NULL,
' notifiable_type ' VARCHAR(10) NOT NULL,
`relation_id_1` INT unsigned,
`relation_type_1` VARCHAR(10),
`relation_id_2` INT unsigned,
`relation_type_2` VARCHAR(10),
' updated_at ' TIMESTAMP NOT NULL,
' created_at ' TIMESTAMP NOT NULL,
PRIMARY KEY (`id`)
);
上面的问题是什么,如何改进?
建议的表设计的关键问题是 object_id_X
and object_type_X
fields. 当数据可以像这样存储在相关表中时,增加命名字段被认为是糟糕的设计:
Notifications Table
CREATE TABLE `notifications` (
' id ' INT NOT NULL AUTO_INCREMENT;
`type` INT(8) NOT NULL,
' notifiable_id ' INT unsigned NOT NULL,
' notifiable_type ' VARCHAR(10) NOT NULL,
' updated_at ' TIMESTAMP NOT NULL,
' created_at ' TIMESTAMP NOT NULL,
PRIMARY KEY (`id`)
);
Notification Relations Table
创建表notification_relations
' notification_id ' INT unsigned NOT NULL,
' relation_id ' INT unsigned NOT NULL,
'关系类型' VARCHAR(10) NOT NULL,
主键(' notification_id ')
);
在您自己的API请求中集成第三方服务时,一个常见的问题是必须等待响应, and as such, 迫使用户等待更长时间.
你会如何避免这种情况? 如果合适,请列举任何相关技术
解决这个问题最有效的方法是使用队列.
当向我们的API发出请求时,将创建一个单独的作业并将其添加到队列中. 然后,该作业将在请求的端点上独立执行, 从而允许服务器无延迟地响应.
有许多队列提供程序,但最值得注意的是:
- Amazon SQS
- Redis
- Beanstalkd
申请加入Toptal的发展网络
并享受可靠、稳定、远程 自由的全栈开发人员工作
尽管这个问题的答案存在争议,但广泛接受的做法是使用 409 Conflict
HTTP status code.
返回a也可以接受 422 Unprocessable Entity
.
Some may argue that a 400 Bad Request
is acceptable, but we discourage this, 因为它通常意味着服务器不理解请求, which in this case is not true.
如果API中的数据是可公开访问的,那么, technically, 完全防止数据抓取是不可能的. However, 有一个有效的解决方案可以阻止大多数人/机器人:速率限制(也称为节流)。.
节流将阻止某个设备在规定时间内发出规定数量的请求. 当超过定义的请求数时,a 429 Too Many Attempts
HTTP error should be thrown.
注意:使用不止一个IP地址来跟踪设备是很重要的,因为这不是设备唯一的,并且可能导致整个网络失去对API的访问.
其他不太理想的答案包括:
- 基于用户代理字符串阻止请求(很容易绕过)
- 在前端为访问者生成临时“会话”访问令牌. 这并不安全:在前端存储秘密可能会被逆向工程, 因此,任何人都可以生成访问令牌.
考虑以下两张表:
CREATE TABLE `posts` (
' id ' INT NOT NULL AUTO_INCREMENT;
`text` TEXT,
' user_id ' INT unsigned NOT NULL,
' updated_at ' TIMESTAMP NOT NULL,
' created_at ' TIMESTAMP NOT NULL,
PRIMARY KEY (`id`)
);
CREATE TABLE `post_likes` (
' post_id ' INT unsigned NOT NULL
' user_id ' INT unsigned NOT NULL,
`created_at` TIMESTAMP NOT NULL
);
中检索所有数据的查询 posts
table for a given user_id
. 除此之外,返回的记录集还应该包括的计数 post_likes
for each post.
首先,也是最重要的,答案应该包括一个,而且只有一个查询. 达到预期结果的方法有很多,但正确的方法是:
SELECT
posts.*,
COUNT(post_likes.user_id) AS likes
FROM
posts
LEFT JOIN
post_likes
ON posts.id = post_likes.post_id
WHERE posts.user_id = 'XXX'
GROUP BY posts.id
The key attributes here are srcset
and sizes
. 这些属性允许开发人员为一个图像指定多个图像大小 , for example:
By using srcset
and sizes
, 然后,浏览器将根据访问者视口的大小智能地选择要使用的正确图像源.
任何基于视口大小使用JavaScript更改图像源的建议都应该被视为危险信号. 这表明开发人员没有跟上最新的CSS特性支持和/或最佳实践.
从技术上讲,有多种方法可以实现这一点. 然而,如今,有一种“正确”的方法来做到这一点:使用 display: flex
and margin: auto
.
Other methods include position: absolute;
, top: 50%
, and margin-top: -Xpx
,但是自从引入了 display: flex
.
为了建立一个网站优化的有机搜索引擎排名, 在整个代码中实现某些标准是很重要的. These include:
- Specifying an
alt
tag on images - 为内容层次结构i使用正确的HTML标记.e.,
/
/
and
p
- 将网站连接到公司的社交页面
- Add an XML sitemap
- Avoid broken links
- 使用虚荣/友好的url(人类可读)
- Add a robots.txt file
- 整合谷歌分析(或替代)
- 指定一个favicon,用于指定特定于浏览器的图标
- 确保闪电般的页面加载时间
- Avoid JavaScript errors
- 优化资产(包括最小化)
- Enable and force SSL
- 为每页指定唯一的标题,但不能超过70个字符
- 在每一页都包含一个元描述
- 确保有足够的内容和足够的相关关键词(如果所有页面都是一句话页面,搜索引擎会惩罚你的网站)
- Leverage browser caching
- 避免W3C标记验证错误
- Specify relevant meta tags
优化网站是一门很少有人熟悉的艺术. 工程师能想到的就越多, 他们就越有可能在编写代码时自然地执行以下所有操作,而不必稍后返回.
(此外,通常一个专业构建的网站在分析时应该得分超过75% gtmetrix.com,这也可以作为一个清单.)
- Optimize all assets
- 将所有资产放在一个单独的、无cookie的域中. Using a CDN is best
- Avoid inline JavaScript and CSS
- Enable gzipping
- Ensure all code is minified
- Defer parsing of JavaScript
- Use
srcset
for responsive images - Leverage browser caching
- Reduce DNS lookups
- Avoid duplicate code
- Avoid URL redirects
- Enable HTTP keep-alive
- Serve scaled images
- 在适当的地方使用图像精灵
- Prefer asynchronous resources
- 指定服务器级别的字符集
- Avoid CSS
@import
- Specify a cache validator
- Minimize request size
- Avoid bad requests and 404s
- Specify image dimensions
- Reduce cookie size
- Make fewer HTTP requests, i.e.,加载尽可能少的外部资源
- Avoid unnecessary images; where possible, use CSS
- 确保没有W3C验证错误
面试不仅仅是棘手的技术问题, 所以这些只是作为一个指南. 并不是每一个值得雇佣的“A”候选人都能回答所有的问题, 回答所有问题也不能保证成为A级考生. At the end of the day, 招聘仍然是一门艺术,一门科学,需要大量的工作.
Why Toptal
Submit an interview question
提交的问题和答案将被审查和编辑, 并可能会或可能不会选择张贴, 由Toptal全权决定, LLC.
寻找全栈开发人员?
Looking for Full-Stack Developers? 查看Toptal的全栈开发人员.
Leah Sapan
Freelance Full-Stack Developer
Leah is a motivated, self-taught, 拥有超过13年专业软件开发经验的分析思考者. 她有丰富的建筑经验, developing, 部署全功能的web应用程序,专注于用户体验和高性能的后端设计. Leah可以在软件开发生命周期中管理多个项目, 在充满挑战的环境中茁壮成长,以满足严格的最后期限, 并且对指导和帮助同事成长充满热情.
Show MoreMatthieu Pons
Freelance Full-Stack Developer
Matthieu是一名全栈软件工程师,在前端和后端开发方面拥有超过15年的实践经验. 他对产品的专注使他与人合作经营了一家媒体机构,甚至创办了一家初创公司. 总是寻找具有挑战性的学习机会, Matthieu探索了机器学习领域,并编写了一个快速高效的推荐系统,至今仍在为最终用户服务.
Show MoreCarlos Ramirez III
Freelance Full-Stack Developer
Carlos是一名专业的软件工程师和全栈web开发人员,专注于Ruby on Rails框架. 他在科技公司工作了十多年, 帮助建立以技术为基础的企业. 他拥有威廉姆斯学院计算机科学学士学位.
Show MoreToptal Connects the Top 3% 世界各地的自由职业人才.
Join the Toptal community.