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状态.
考虑下面的数据库表设计:
创建表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
创建表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, 因为它通常意味着服务器不理解请求, 在这种情况下,哪个是不正确的.
如果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
- 避免内联JavaScript和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的全栈开发人员.
Jonathan Rhone
自由全栈开发人员
Jonathan是一名拥有十多年经验的全栈工程师. 他擅长大型分布式系统和面向客户的单页web应用程序. 乔纳森还擅长大数据,经常参与与社交媒体相关的分析项目.
Show MoreCarlos Ramirez III
自由全栈开发人员
Carlos是一名专业的软件工程师和全栈web开发人员,专注于Ruby on Rails框架. 他在科技公司工作了十多年, 帮助建立以技术为基础的企业. 他拥有威廉姆斯学院计算机科学学士学位.
Show MoreMatthieu Pons
自由全栈开发人员
Matthieu是一名全栈软件工程师,在前端和后端开发方面拥有超过15年的实践经验. 他对产品的专注使他与人合作经营了一家媒体机构,甚至创办了一家初创公司. 总是寻找具有挑战性的学习机会, Matthieu探索了机器学习领域,并编写了一个快速高效的推荐系统,至今仍在为最终用户服务.
Show MoreToptal Connects the Top 3% 世界各地的自由职业人才.
Join the Toptal community.